NetBSD Emmanual Dreyfus says that COMPAT_DARWIN is now able to run MacOS X’s XDarwin (X11). Darwin is Apple’s MacOS X core. A fully functional Darwin binary compatibility on NetBSD/powerpc & NetBSD/i386 will imply getting MacOS X libraries to run any MacOS X program, just like NetBSD is now able to run binaries from Linux, FreeBSD, Solaris, and many other OSes. In the meantime, a very interesting slide show was released about DragonFly, showing many aspects of the work Matthew Dillon and cia are working on.
Binary Compatibility of Darwin on NetBSD; DragonFly BSD Slides
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
NetBSD does nothing but impress! Awsome work!
– J
I can’t wait until they get WindowServer running. I think it would be fun and educational to use the NetBSD kernel (or FreeBSD if they merge this code into their PPC tree somewhere down the line) as a drop-in kernel for XNU, just to see how much of OS X’s responsiveness (or rather lack thereof) is due to XNU itself.
“drop-in kernel” should be “drop-in replacement”
netbsd rocks
I’m looking forward to having Dragonfly 1.0. If Matt Dillon’s theories work out in practice, I may even let FreeBSD go.
“I’m looking forward to having Dragonfly 1.0. If Matt Dillon’s theories work out in practice, I may even let FreeBSD go.”
I am wondering if I’ll do the same myself. Time will tell. At any rate, you can be sure that the best features of DragonFly (the ones that blow anything on FreeBSD away) will be brought back into FreeBSD, if slowly.
rock!
but…
It would be nice if someone would fix the bug that one can use native XFree on OldWorld PPC’s.
-A
At any rate, you can be sure that the best features of DragonFly (the ones that blow anything on FreeBSD away) will be brought back into FreeBSD, if slowly.
How could you be sure? Matthew’s approach to SMP is entirely different and he had to start with 4.x codebase. To import what is cool in DragonFly it could be necessary for the FreeBSD team to throw away all the mutex based SMP locking code they did so far (which is pretty much what 5.x is).
Okay, I shouldn’t have used the word sure, I should have used the word likely. It would be a slow transition at any rate, and it would only be undertaken if DragonFly really blows FreeBSD 5.x away performance wise.
You are right about the differences, and their effect on any possible future transition. But there is a two way exchange here, and the best of both worlds will likely (eventually) be found in all.
That’s my slightly informed opinion.