Insanely Mac

It was said from the beginning: "it is only a matter of time." A team of developers have now successfully ported the Linux 2.6 kernel to run on the iPhone, along with a new bootloader called openiboot that is capable of booting both Linux and the iPhone OS.

From the Linux on iPhone blog:

"What we have:

- Framebuffer driver
- Serial driver
- Serial over USB driver
- Interrupts, MMU, clock, etc.

What we have in openiboot (but hasn't been ported yet):

- Read-only support for the NAND

What we don't have (yet!):

- Write support for the NAND
- Wireless networking
- Touchscreen
- Sound
- Accelerometer
- Baseband support

The current userland we're using, in the interest of expedience, is a Busybox installation created with buildroot, but glibc works fine as well, and we're going to build a more permanent userland solution."

A video has been submitted to vimeo demonstrating the functionality of openiboot and the process of booting Linux.

Instructions for installing this preliminary version of openiboot and/or the Linux kernel are available, but currently require a Linux console to execute.

The necessary files may be downloaded from here.

Congratulations to leader planetbeing and contributors CPICH, cmw, poorlad, ius, and saurik for this fundamentally important achievement!

The new MacBooks, MacBook Airs and MacBook Pros are here!

They were first brought to light for InsanelyMac to see from sharp-eyed Engadget reader TheHAWKS:
http://forum.insanelymac.com/index.php?showtopic=131100

Someone has already claimed to have gotten a 9600GT (G94 core) working using the new kexts in this thread:
http://forum.insanelymac.com/index.php?sho...131914&st=0

Also, netkas has posted that these kexts could be used for getting the Radeon 4XXX series cards to work.
http://forum.insanelymac.com/index.php?showtopic=131374

This is the link to the full system profile of the new MacBooks, from which we can find out several things:
http://apcprojects.com/system-profiler.pdf

The build number for the MacBook installs is 9F2114 which is using a (shock) NFORCE chipset, MCP79 AHCI Chipset using AppleAHCIPort.kext version 1.5.2, whereas our 9F33 10.5.5 version is using 1.5.1. It also has an IOAHCIFamily.kext and no IOATAFamily.kext

They’ve both received internal and external revamps which some hate and some love. They have a body made from one solid piece of aluminum which is promised to be thinner, lighter, and greener, with an LED backlit display. The more expensive MacBook option comes with a backlit keyboard, as do both of the new MacBook Pro offerings. The trackpads are made of glass on all the new notebooks.

Graphics: They’ve all got brand new nVidia GeForce graphics cards, the MacBook and MacBook Air both have a nVidia GeForce 9400M with 256MB of shared DDR3 SDRAM, while the MacBook Pro has both a nVidia GeForce 9400M and a 9600M GT with options for either 256MB or 512MB of GDDR3 VRAM.

The “old” MacBook is still available (at a lower cost) with the integrated Intel GMA X3100 with 144MB of shared DDR2 SDRAM. The “old” MacBook Pro with the nVidia GeForce 8600M GT still has 512MB of GDDR3 VRAM.

Processors: The MacBook has options for 2.0GHz and 2.4GHz Intel Core 2 Duo. The “old” MacBook has a 2.1GHz Intel Core 2 Duo. The MacBook Air has 1.6GHz and 1.86GHz options. The MacBook Pro can come with either 2.4GHz or 2.53GHz, with the “old” MacBook Pro remaining at 2.5GHz.

RAM: 2GB is the standard RAM on the new MacBooks, with the “old” MacBook remaining at 1GB standard. MacBook Air comes 2GB standard. 2GB is standard on the least expensive of the MacBook Pros, but 4GB is standard on the higher-end MBP, as well as the “old” MBP.

Display: All of the MacBook/MacBook Air offerings are 13.3-inch glossy. The new MacBook Pro is offered only at 15.5-inch glossy as well, no 17-inch or matte option there, the only matte (“anti-glare” or non-glossy) option, or 17-inch option for that matter, comes with the “old” MacBook Pro.

Hard drive: The new MacBooks come with options for 160GB, 250GB, 320GB (all 5400 rpm SATA) or a 128GB Solid State Drive (à la previous gen. MacBook Air). The “old” MacBooks come with options for 120GB, 160GB, or 250GB (all 5400 rpm SATA).

The MacBook Air offers only two choices, a 120GB 4200 rpm SATA, or a 128GB Solid State Drive (which ups the price by $500 USD).

MacBook Pros have many more options, 250GB at either 5400 or 7200 rpm, 320GB at either 5400 or 7200 rpm, or 128GB Solid State Drive. The “old” MacBook Pro comes with 320GB at 5400 or 7200 rpm, or a 128GB Solid State Drive.

Battery life: The “old” MacBook and the MacBook Air both come with a promised 4.5 hours of wireless productivity, while every other option (new MacBook, MacBook Pro, and the “old” MacBook Pro) all offer 5 hours of wireless productivity. This can most likely vary greatly, especially with the option for reducing the power consumption of the graphics card with a new power saving feature which must be restarted to work, offered by a new kernel extension “AppleGraphicsControl.kext” .

Gigabit ethernet (except on Air), airport extreme N, and iSight are all standard, for usb/firewire options the MacBooks only offer two usb 2.0 ports, the “old” MacBook has two usb 2.0 and one firewire 400. The Air comes with one usb 2.0 port, the MacBook Pro comes with two usb 2.0 ports, one firewire 800, and one expresscard/34 slot, while the “old” MacBook Pro comes with three usb 2.0 ports, one firewire 400, one firewire 800 and one expresscard/34 slot.

First off I would like to state that this is my first post on the forums, but I have been reading them for quite some time now. I just want to show my appreciation in any way possible and for now the best way may be to share my true mac story! I also would like to apologize in advanced for I am nearly certain that this isn't the best place for this topic, if a moderator would kindly move it to the appropriate location I would be grateful.

Let's begin with the short history of my computer usage. I am currently 23 years old and live on my own, blah blah. I got my first computer when I was 8 (an OS/2 with it's own special OS which we removed and loaded Windows 3.11, my dad and I struggled for months to replace the PC-DOS with MS-DOS, I don't remember much else). I later sold that computer and replaced it with one that had Windows 95 and I was filled with glee, to say the least! I struggled on both computers with understanding how sound/video drivers work. If memory serves correctly that computer had 16-colors because I didn't have the proper video drivers. I tried to sell this computer to gain a replacement, but the person who purchased it was my father's boss's daughter (lol) and she whined enough that my dad's boss put him into a position where he had to spend the money they bought the computer with to upgrade it to their standards. I lost my computer .

Once I hit 7th grade (or the summer after), I began working for my dad's company part-time doing data-entry and production work and I gained enough money to build my FIRST computer from scratch. Before this I helped my dad once make his custom PC and we learned quite a lot through trial-and-error. I was able to build a Cyrix M3 300mhz PC with Windows98 and a 4.3gb Hard Drive (lol?). I don't remember much else about the hardware specs. I do remember buying my first DVD-Rom drive and adding it to the machine though!

That computer eventually became virus infected and reformatted multiple times. I got my hands on a real-deal copy of Windows 2000 Professional/Server Beta3 Public Test CD (a set of CD's actually) and I toyed with that for a while.

In favor of shortening the story I'll advance quicker through time: Throughout high-school my brother and I competed at who could build the best computer and through a series of upgrades (piece at a time) I went through probably 3 PC's worth of parts over the years, and by senior year I had an Athlon XP 2100+, water-cooled and over-clocked to 2.2ghz (equivalent to I believe a 2800 or 2900+ for those who don't understand AMD ratings). It was around this time that I began toying around with dual-booting Linux (Redhat 9 was my first). I got a laptop as part of a program for college and was pretty steadily back on windows after this time (I struggled with linux drivers, otherwise I loved it... still needed windows for gaming however). I began a summer job at a local Computer Repair shop (also built customs) in downtown mpls. It was here where I gained my first positive encounter with Mac OSX. A co-worker (who is now a very very good friend) introduced me to his iBook. I called him a traitor, as I was an avid PC fanboy who utterly despised Mac for no real reason at all. He finally convinced me (by locking me out of my computers and forcing me to pay him back by learning how to lock him out of his) to give them another chance. I fell in love with the OS. It was 10.2 if I'm not mistaken and it was gorgeous and intuitive and revolutionary and pretty much kicked Windows' a$$ in every aspect imaginable (imo).

After this I dug out my old copies of WindowBlinds (Stardock) and began trying to transform my Windows UI to look more mac. I used ObjectDock (Stardock) and other such mods to attempt to recreate the OSX environment on my PC. There were many failures but ever since that summer I always had an OSX skin of some sort on my PC. In my 2nd semester of college I became severely frustrated with my gateway laptop (and now hate gateway because of those awful computers) and traded it in for a real mac! (iBook:G4 with 768mb Memory 12" LCD). I was happy for the entire 2 years I had that computer (I sold my PC as I hated using it now).

I had to get rid of my Apple because it was under a lease with the school and I was violently shoved back into the Windows world where I frequently became angry with my computer and it's inability to be as pretty as OSX and function as well. I decided it was time to Linux as my hatred for windows had flamed into something uncontrollable. For me, windows had to be there as I play WoW so it was always installed. That is, until after 2 destro's worth of Fedora, I switched to Ubuntu (um... /drool /drool omghax it's COMPIZ-FUSION!!!) and started toying with Wine (had experience with Xine on my Apple attempting to run certain simple midi-based software on my G4). I was able to get WoW working. Long story short I was forced back into windows due to drivers not functioning properly and though everything native to linux worked, things like WoW and my guitar software and Ventrilo would never play nicely together. That and Dual-screen Compiz-Fusion not working with xinerama (the proper dual-screen option, the other option is frustratingly stupid at window management, also spans the bars across both screens and multiple resolutions was leaving me with space I could not access) led me back into Windows.

I've always read through these forums and wondered if I could get OSX on my pc. I always read the guides and saw things like "this is not for everyday use", or "this is a hobby and is extremely difficult" and was scared away at the though of not being able to enjoy OSX as things just wouldn't work properly. That and I use AMD and always will (Intel has better hardware, I know, I don't support their company and refuse to buy their product for reasons I won't get into). Well one weekend I was bored with WoW and my son was away and I happened to pick up a Kalyway disk for fun. I figured what the H3ll... I'll give it a try!

I didn't make it into the installer.

I have never, in my life, ever given up on anything that easily so I hit the forums and I hit them harder than I ever have (not posting as there is a plethora of information amongst the numerous noobular posts asking very simple things that can be easily googled for and I didn't want to add to the clouds of dust I had to sift through to find the real expert answers). I downloaded another distro, Lawless PPC I believe it is called. I was able to sometimes get into the installer but it would freeze up on the Apple most of the time. After some research I found an odd solution suggesting re-burning the image at the slowest speed permitted by the burner.

After doing this I got past the “Still waiting for root device” errors during setup and I reached my first taste of Aqua on my PC. I had made it into the installer. I ran my first setup of OSX onto my IDE 120gb drive and ventured into firstboot but never saw it happen. I did –v to see what was going on during boot and found the “Still waiting for root device” error again. I attempted many solutions like rd=disk0s1 at boot and such but never got in. I decided to switch around my hard drive configuration to be just the DVD and the target hard disk. I put the hard disk on master and the DVD on slave and got setup to run, finish, and my computer made it into firstboot. I chose randomly at the customize option as far as device support goes. I got a basic install with no video support, sound, or internet and had to dual-boot to windows to get things working.

I wrote down all of my devices, their ID’s for Vendor, Device, and Subsys and started researching. I was able to easily mount my windows hard disk from within mac so I could grab downloaded zips right off of my windows desktop folder when booted into osx. I tried various kexts for either net since that, obviously, would allow me to stay in osx for future research.

I was having some issues here and there getting things to work properly. Little history on the target disk: It was an old 120gb drive that occasionally would repeatedly click upon boot not allowing the BIOS to recognize it (where I would reboot the computer until it would POST without clicking). I found an old USB->IDE kit and stole the power source from it and got the 120gb to run off of that without clicking and from there on out powered it that way (to prevent the clicking issue on reboot). Well I decided I had enough of this, I was certain that if this OS was successful I would not want it on this drive anyway so I headed to BestBuy and picked up a new 500gb Sata3 (I went with the sata ignoring the potential for issues resulting in attempting to install with an unsupported raid controller). I started setup from scratch (this time choosing more appropriate driver options right out of the box). My chipset was not listed (it’s an AMD chipset on a Gigabyte board, which btw numerous guides say is very very difficult to get fully functional and is highly recommended against using for a haxintosh) so I selected VIA since I was fairly certain it shared many of the same components as mine (Realtec Audio/Ethernet). I also selected the proper NVInjext for my N’Vidia 7800GT 256mb card and was greeted with functioning video on first boot with dual-screen up and running out of the box, Ethernet as well.

Having those two out of the way right away was incredibly helpful (even though I think I could have fixed the video with no problems at all but the Ethernet I was still not sure which kext to use). I was able to enable the sound very simply without doing anything too serious. At this point I began installing OSX applications and getting everything organized.

I pretty much googled around the web (90% of results came from insanelymac forums) for solutions to problems I was having, mainly small glitches. I got everything in order, and last night I was able to get my final primary goal accomplished, I got my 6ch Surround Sound working (or 8ch, I have 4 stereo output devices and I can map them around however I please which is fantastical!). I tried many different kexts and packages for the ALC888 driver (the one that finally worked was the ALC888Audio.mpkg that I got from http://forum.insanelymac.com/index.php?showtopic=34075 after hours and hours of searching.

To conclude this I would like to give my thanks to every single person that has poured hours and hours of effort into developing fixes and/or work-arounds for the problems generated by running osx on non-native hardware. I would also like to thank those who put together the “patched” install DVD’s, not to mention the people who worked so hard to incorporate AMD support into the project. And I cannot neglect thanking the people that pay for, maintain, moderate, administer, and develop this absolutely amazing and helpful community. In my entire history with computers, I have never, ever been happier. Thank you SO much. I wish I had what it takes to contribute back but I just don’t. I hope this article encourages the less experienced to not give up on their osx86project of their own, as well as encourage the geniuses out there to continue helping us enjoy an absolutely amazing operating system on our custom PC’s.

THANK YOU INSANELYMAC!!!

Kernel development has long been considered a black art in the osx86 community, but recently new initiatives have grown up which show that the xnu kernel, the very heart of both Darwin and OS X can be handled in a collaborative, opensource manner. We had a word with the maintainer of the voodoo xnu kernel source tree, Mercurysquad, to find out more on how this works, how it came to be, and how *you* are invited to be part of this ongoing project.



IM:
So where did all this start? with the ToH patches?

Mercurysquad:
Yes indeed, netkas released the "ToH" source patches for the 9.2 kernel on his blog sometime back in May (if i remember correctly) that gave us the kickstart into getting stock apple sources to work on machines they didnt officially support. Over time however we have rewritten almost all of it, so that now not much of the original toh sources remain.
My initial motivation was to get speedstep working properly on my pentium-M laptop. The speedstep patch, which paulicat wrote, was working fine on intel's core or higher CPUs, but it would make the system timer run slower on older CPUs like the pentium M, making it almost unusable. after I fixed this trivial issue (there was a bug in the timer scale calculation), I still had quite high temperatures on my laptop cpu.
Plus the cpu throttler kext written by Niall Douglas also had some deficiencies, so i started writing a new kext which would also allow undervolting the processor, and then came some more changes, and more and more.. At some point we realized the entire clocking code in xnu was based on too many assumptions, so after a lot of discussions we changed the realtime clock code so it would work properly on new and old cpus alike.
With so many changes already in, I thought it was better for the general OS X community to benefit from this kernel, and I made the first beta release. it just progressed on from there.

IM:
I get the impression this kernel is more of a team effort than previous iterations?

Mercurysquad:
Indeed it is. when i made the speedstep kext, I put the entire source code online under a bsd license. this was picked up by Superhai, who made massive improvements to it, giving better support to most cpus. On the other hand, with the kernel, a lot of groundwork was done by Turbo with the rtclock fix, we also collaborated on writing a new sse3 emulator.
All of us believe that collaboration is the key: Not releasing sources, or keeping them closely guarded hampers the progress.

IM:
The results seem to bear that out.

Mercurysquad:
absolutely. and so you see within the short span of 2 months we are close to solving most of the problems that had been plaguing the community. People can finally get speedstep and sleep working together, the kernel is more secure with NX bit enabled on supported system, and the sse3 emulator is totally rewritten to be multithread capable, and 3 times faster, all this because we offered our time and shared our know-how.

We'll release the full sources as a patchset (nicely commented and tagged with explanations and original contributor's names) as soon as the final kernel is released, and hopefully we'll see many new developers join us in improving this great kernel

I'd like to mention that, a few months ago I was a total newbie to xnu. I was unable to compile the kernel
But with the help of all those in irc and on IM, it was not too difficult to get started. There are still a lot of kinks, for example, compiling xnu is very messy if your system is not setup already
Apple's build environment seems to be setup in a very different way than traditional gnu/linux environments, despite being "unix"-like. Once again, thanks to great work done by Dense, we have a script which automates getting the sources, patching them, setting up the build environment and compiling the entire kernel -- all in one command.
We decided it is very important to make it easy for new developers to join in, so we have the voodoo build script, as well as nicely commented out source with explanations of each change we made compared to stock sources. Much of it is also because we want to shed the 'hackintosh' image and look at ourselves as a proper open-source project.

IM:
This seems to be a growing trend within darwin/os x?

Mercurysquad:
It's important to become 'friends' with apple so the flow of information can happen in both directions, this will help position darwin as a viable alternative among the various flavors of unix, thus benefitting apple, and apple's support will help us improve the kernel to support more platforms. There are various flavors of darwin and nextstep as well:
We have openstep/gnustep which implement most of the cocoa api, putting a proper xnu kernel behind it will give us something very close to an all-opensource mac os.
But all this requires that more people help with the development

IM:
So.. a development process like that must have had its highs & lows.. can you remember any particular roadblocks that were frustrating, any particular breakthroughs that had you popping champagne corks?

Mercurysquad:
Perhaps the biggest roadblock for most people including me was to understand how the build process is setup, and how the kernel works. the kernel is very different from linux for example, and also doesnt have the exposure that linux does. amit singh's excellent book about the kernel was a great help. Another problem we had was not having an active maintainer to really drive the process.
Almost everyone has switched to vanilla kernel, prushing people like me as an sse2 user (and one with quite a bit of time!) to think about legacy support as well, and because of all the discussions it stirred up, turbo came forward with his excellent rewrite of the sse3 emulator

IM:
That's the 3rd? 4th? sse3 emu?

Mercurysquad:
It's the 3rd 'generation'; the original one was written by the great maxxus, as everyone knows, but it was quite slow and incomplete. Semthex/rufus/oui improved it a lot, making a complete emulator but it had its problems - its design forced us to have a writable commpage area (which is otherwise read-only), and it also limited us to only 2 (or 4) threads of sse3 emulation at a time.

Some time back, turbo started writing a user-space emulator for the AppleTV. The old emulator resided in the kernel (although emulation was mostly userspace). In the appletv, you cannot swap the kernel without losing functionality, prompting turbo to create a userspace emulator, but it was too slow to port over to regular computers. So with inputs from turbo i started writing a fully reentrant emulator for PCs, but without much assembly experience i couldnt get very far. Turbo finally ported his emulator to xnu, and i helped with the testing and gave inputs until it was able to boot the entire gui. the difference was that it could run any number of threads.

The old emulator could only run up to a fixed number of threads, with each "slot" taking a lot of space in the commpage (which has a limited number of memory pages)
The new emulator was tested with 90+ threads and it worked without a hitch. This also fixed long standing issues with, for example, iCal, or fs_usage, or Logic Pro. Turbo's original version took advantage of gcc's code generation and made simplifying assumptions of which instructions to emulate, but it turned out in leopard apple has used a lot of exotic sse3 operands, so to counter this i wrote an operand decoder which would allow 100% of the sse3 opcode/operand combinations to be emulated, and thus the 3rd generation was born.

I remember when we did the first benchmark against the old emulator we were expecting it to be about 20% slower.
To our surprise it was 2 times faster. We figured it was because of the commpage write that the old emulator used. i also pushed turbo into optimizing the emulator further and gave suggestions... Now the final version is 3x faster
We had the ingenious idea to patch one of the isntructions (lddqu) directly, making it some 400 times faster. This worked fine but some hard to avoid technicalities with the memory manager forced us to abandon it.
This new emulator is still on an average 3x faster, and finally allows everyone to run any sse3 apps without failure.

And this is not the biggest celebration we've had ..
As I talk with you, people on the "voodoo" team are testing something big

With great work done by "kaitek", i'm happy to announce that we have an on-the-fly opcode patcher
This would mean AMD users could run any application which specifically tests for intel cpus - without having to rely on decrypts or patched versions

IM:
That's nothing short of revolutionary... and it works?

Mercurysquad:
It's another step in our vision of unifying the various "types" of the xnu kernel into one universal kernel for all. AMD users will not longer have to wait anymore for special versions of apps / kernels. Going by initial testing i have just done some hours ago, it works 100% Although there are some issues with performance under a lot of stress on the memory manager. We are stress-testing it to make sure it offers no regression.

IM:
I guess this opens for retail installs on AMD as well?

Mercurysquad:
Yes AMD users can now install retail as long as they use this kernel. While this may still not be technically fully vanilla - which usually refers to using 'vanilla' kernel in addition to all other parts of the OS, it is still a great step for all amd users where they now will enjoy the same benefits as intel users do. Also, an added bonus for SSE2 intel users is that we can patch any opcode, so the lddqu issue I talked about earlier with the emulator, vanishes. we get 400x faster lddqu emulation compared to the previous 3rd generation emu's lddqu routine. As lddqu is also the 2nd most used opcode, this will improve performance of applications a lot. We still need to run benchmarks on whether the performance hit of on-the-fly patching for sse2 is higher or lower than the performance gain we'll see by patching it, but for amd cpuid emulation, this is not an issue, as cpuid is not performance critical and very sparsely used.
Kaitek built an entire disassembler for this, which is blazingly fast. From our initial reports, it was able to dissassemble and patch microsoft word (a 40 mb image) in 200 milliseconds. There have been other changes by me to the timestamp counter and cache detection routines which adds support for a lot of legacy CPUs. this part of the code was somewhat 'hackish' in the ToH source. we are now perfecting these changes. Once we can verify that there are no regressions in functionality/platform support compared to current toh kernels, the 'voodoo' kernel will be available for all

IM:
It seems to me that on-the-fly patching is a bit of a paradigm shift.. whether used for cpuid or sse3 emulation

Mercurysquad:
it is similar in spirit to rosetta: While rosetta has to translate every PPC instruction into intel, we only translate what is required. It's also true that rosetta has a performance hit, and so does our opcode patcher, but being in-kernel, and heavily optimized, it will have (imo) no *noticeable* performance hit (i'm running this kernel as we talk). Also because rosetta keeps track of translated instruction blocks and has to translate complex jump/branches. In our case, it is simple a patch of the cpuid instruction to the 'int 0xfb' instruction so it has no memory footprint either. The current issue we have is that we can only patch in what fits within the length of the opcode to patch so not all sse3 (or other) instructions can be patched, which means the sse3 emulator will stay within the kernel for some time, however given its primary purpose as a cpuid emulator, it serves the amd community very well. We have word from Leo4All that the next iteration of the dvd will include voodoo kernel. We are hoping that all distros will switch to this unified kernel so that we avoid fragmenting efforts within the community. In essence, we can forget about 'intel/amd/sse2/sse3/nohpet/sleep/speedstep/nonx' tags completely!
You drop this kernel on your system - it works (well except for certain old pentium4 users, but we are also collaborating with the Chameleon bootloader developers to fix this issue as well)

IM:
What's the issue?

Mercurysquad:
The issue is with the new clock initialization routine. David Elliot (otherwise known as 'dfe') has a nice fix to disable hpet on unsupported systems, so we decided to remove the hpet emulation entirely since its only consumer - the apple supplied speedstep driver - is replaced by our speedstep kext and we replaced the clock initialization routine to read the bus ratio directly from the processor. This is implemented by all AMDs and most intel processors from pentium M and pentium 4 model 3 and above but the old willamette and northwood core p4's don't have this register. We had the choice to put a clock timing routine in the kernel to calculate the cpu frequency / bus ratio without which xnu will panic, but we learnt that the chameleon bootloader already does this so instead of reinventing the wheel we simply asked the chameleon devs to also export the cpu frequency in addition to the fsb frequency in the fake EFI tree. For users who cannot or do not want to upgrade their bootloader, there is a boot-time flag they can set to explicitly pass their bus ratio to the kernel.The patch for chameleon is already in their repository, and the build will be released at the same time as the kernel so P4 users dont have to wait (collaboration ) it seems this is a recurrent theme.

We are hoping other projects, perhaps openstep/gnustep, could benefit: The linux source code is very complicated and large, but xnu being a hybrid micro/macro kernel is just a 7.5 mb download, and compiles in minutes, which means it's a good study tool for anyone interested in kernel development. (specially when Amit singh's excellent book Mac OS X Internals is used with it!) The origins of the xnu kernel can also be traced to an academic institution (Carnegie Mellon to be specific) which wrote the mach subsystem of the kernel. Mach is however a microkernel, while xnu is not. This is a design decision made by apple, to combine bsd and mach into one. (studying how it's integrated is also interesting for a lot of engineering students)

IM:
I've got a vague idea what a microkernel is, and what a monolithic kernel is.. is there a short explanation of where xnu falls & what the difference is?

Mercurysquad:
a microkernel like mach only contains the most basic code to initialize the processor and memory, and be able to create threads/processes and pass messages between them. Almost all other functionality, including often the hardware drivers, are in userland (ie. less privileged), but this means that they all have to communicate with the microkernel very often and this is slow. A monolithic kernel like linux takes a different approach: All drivers, and a lot of the other components, like the networking stack, are put directly into the kernel as one huge binary (to put it simply) which loads once, and shares memory so the performance is better, but this also means, a failed/crashed driver (or another subsystem) will crash the entire system, or compromise the security, so it's a tradeoff between performance and stability/security.

Apple chose an almost-monolithic path in that the mach microkernel, the BSD subsystem (which provides the "unix" services) and the driver interface are all one binary which share memory, thus being fast, but they are built as separate components and linked together. Most of the other componenets like drivers are loaded later (but also end up in the kernel) so it's still a bit more modular than linux, but not completely a microkernel. Apple decided that a failed userspace with the kernel running is still a crashed system from a user's point of view so they gravitated towards more performance (we all know apple's systems are stable as well, owing to its tried and tested mach/bsd heritage !)

Apple have also engineered their driver interface (IOKit) brilliantly allowing us to load the same driver binary across different kernel versions and has a nice 'matching' scheme allowing things like the NullCPUPowerManagement.kext which disables apple's speedstep/PM driver or natit, graphic settings injector etc. All of which makes it possible run an unmodified (legally obtained!) os x on commodity hardware.

IM:
Wow.. Thank you for giving us this insight, it's been an education. Is there anything else you'd like to add before we finish?

Mercurysquad:
hmm I'd just like to add that a lot of people have helped us along, tireless testers like bhast2 (leo4all creator, amd testing), sckevyn (who stress tested the sse3 emulator in a professional fashion), motivator/manager Galaxy (who actually got us all together - we wouldn't be doing this if not for him) and the chameleon team, people in IRC and everyone else, so we just hope that we get even more people to help us out!

Latest information: http://groups.google.com/group/xnu-dev/web/home

Mac OS X 10.5.5 has been released and can be downloaded through software updater or Apple's website. 10.5.5 is fairly extensive and the full release notes can be found here.
While this update can be considered 'safe', its good to follow guides such this one to prevent AppleIntelCPUPowerManagement.kext from breaking your install. AMD users can use the AMD Software Patcher for a safe installation.
10.5.5 Combo Update (601 MB)

10.5.5 Update (316 MB)

10.5.5 Server Combo Update (729 MB)

10.5.5 Server Update (341 MB)

Good luck installing, be sure to back up with Time Machine prior to updating