Slashdot Mirror
NetBSD's COMPAT_DARWIN Adds XDarwin Support
Dan writes "NetBSD's Emmanual Dreyfus says that COMPAT_DARWIN is now able to run Mac OS X's XDarwin (this is, the X Window server for Darwin). The server is fully functional: display, keyboard and mouse work. He says that running Darwin has no interest in itself, but having it working ensures that NetBSD's IOKit (1) emulation is good enough to be used. Darwin is Apple's Mac OS X core. A fully functional Darwin binary compatibility on NetBSD/powerpc & NetBSD/i386 will imply getting MacOS X libraries to run any Mac OS X program, just like NetBSD is now able to run binaries from Linux, FreeBSD, Solaris, and many other OSes."
Are you trying to get to a point where you can run any OSX binary, including the Cocoa/Aqua environment itself?
Nifty for sure, but you start to wonder about the usefulness of this...I mean, in order to legally use the more interesting, useful parts of the OS, you would have to own a copy of OSX, unless for some reason the soft Unix underbelly of Darwin doesn't fit your needs, and you want a more traditional BSD, but still be able to use the OSX GUI.
If you're making a unix binary compatibility for just standard CLI or X-Windows, it cries out of 'what's the point'.
So what is the point?
Karma: Chameleon (mostly due to the fact that you come and go).
That would require emulating the Apple's APIs for everything in the OS.
Given that most of it is proprietary, this is very unlikely to happen, though not impossible (just look at Wine)...
AC comments get piped to
The post doesnt make it clear, this is about PowerPC os's and emulation. Doesnt mean you can take X86 code, and run it on the netbsd for PPC.
Remember this is binary compatibility, not emulation: programs run at full speed, but only on a NetBSD machine with the same CPU the program was designed for. Binary compatiblity does not enable running Linux/i386 binaries on NetBSD/powerpc, for instance.
So far Mac OSX only runs on PPC. So if you run NetBSD on PPC, your set. But then, Why not use MOL (Mac On Linux)?
They're trying to get the OSX environment running on NetBSD instead of Darwin. I'm failing to see the point of this other than a different package manager...anyone else see a benefit to this? Drivers? Cheaper hardware? All looks the same to me...
Karma: Chameleon (mostly due to the fact that you come and go).
The goal is to run MacOS X's programs on NetBSD/powerpc. One of the problems is that thoses programs do not use X11, they use quartz.
We have no free software display server for Quartz. Emmanuel Dreyfus had three options to get the job done:
1) Write a Quartz display server
2) Write a Quartz to X11 bridge
3) Emulate enough of MacOS X to get MacOS X's Quartz display server to run on NetBSD.
He chose option 3. It is not an easy job since MacOS X I/O are done through the IOKit, which completely differs from UNIX I/O API.
XDarwin is the X11 server for MacOS X. It uses the IOKit to access the display, keyboard and mouse. Having XDarwin fully fonctionnal on NetBSD means that NetBSD IOKit emulation is in good shape. It is the first step on the right direction.
Next step is to run MacOS X's Quartz display server itself.
while it would be very nice, this DOES NOT let you run OSX apps on linux, not on and i386. This simply lets you run binaries for the PPC processor from OSX on netbsd running on a PPC. Not just any binaries too, just those that dont use the Aqua GUI. Dont really see the point of it aside from it being a nice technical achievement, kinda like running darwin on an i386.. no real point just cool :)
The war with islam is a war on the beast
The war on terror is a war for peace
The point isn't "free" as in "free-OS". The point is embracing open standards.
Apple might have a proprietary OS in Panther but it is based on standards that allow for easy networking and integration into existing frameworks.
"Fighting for peace is like fucking for chastity."
Actually, that isn't the case at all.
/etc structure on your i386, sparc, sparc64, macPPC, prep, m68k, etc. boxes.
NetBSD has a substancial cross-platform 'packages' library of source code and a robust build system. Most packages, when they appear ready for one architecture, are ready and buildable on any other architecture. If you're not going to be running MacOS stuff in that 'Macintosh' API layer(s), you're FAR BETTER OFF running NetBSD/macPPC than you are running Darwin alone on your Apple hardware. Furthermore, if you run multiple architectures, with NetBSD you'll be able to admin the same exact
I threw Darwin on my beige G3 machine last week, from the ISO downloadable from the OpenDarwin project. It installed fine and booted properly (I had specifically told it what drive to install itself on and it instead installed on a different drive, wiping out my MacOS 9 partition, but I don't hold a grudge about that)
I looked at the Unix command prompt, said 'gee whiz, it works, but there's no packages to run' and took it off. I noted while reading the howtos at opendarwin.org that the binary packages they have built require you to use the MacOS X installer to put them on your system.
I do not own a copy of MacOS X. It was a no-starter proposition for me. Nor am I about to buy OS X for a Beige G3 just to install 'free' software packages on it.
A Good Intro to NetBS
Exactly, because Everybody Knows that microkernels are slow.
... then Macs would take over the world!
(Does it count as a troll if you're serious?)
Wait, let me see if I can connect some of them...
Microkernels being slow are the reason Macs are so much slower than PC's! And if Apple would just:
(a) port to x86
(b) drop the microkernel in favor of Linux
(c) allow clones
(d) run Windows apps
(e) use Windows drivers
(f) eliminate their greedy 75% profit margins
Hey, this is fun!
and wonder if you could be doing something more with your life?
"NetBSD's COMPAT_DARWIN Adds XDarwin Support" What the fuck is that? It's not even vaguely english. Probably the majority of people who know what it means are reading this site right now.
Reminds me of (what else) The Simpsons:
Comic Book Guy [reading comic]: "No aquaman... you cannot marry a woman without gills! You're from two different worlds!"
[looks up to see a nuclear warhead streaking towards him]
"Oh, I've wasted my life."
[kabooooom!]
Read Pynchon.
Don't forget, BeOS used a microkernel, and we all know how slow it was. It took almost 15 seconds to boot! I couldn't stand it. I remember how I used to play video games on my game boy to keep me entertained while I waited. And don't get me started on how it could only run Quake 2 25%-50% faster than any other OS. I mean, really, it was unplayable at such speeds. No wonder Be went out of business.
Linus says microkernels suck. I think we should all place our blind faith in whatever he says. So, next time someone comes around offering you a shiney new microkernel, remember to just say "no".
The fact that all Mac binaries are PPC is going to mean at best on i386 platforms you're going to have to use emulation, a better approach is to emulate the Cocoa API allowing a recompile for i386/whatever.
The Cocoa API is basically the NextStep API with Quartz replacing Display Postscript for the display composition/rendering and a number of additional classes and extensions since. (Display Postscript was licenced, Quartz is based on the free PDF specification).
The original NextStep API exists on non-PPC platforms in two forms;
The first is Apple's own implementation which was called 'Yellow Box' back in the NextStep days and let you recompile your apps for Windows. Alas there were licencing issues that Apple claim meant the runtime was expensive to deploy.
Apple still use this runtime in WebObjects for Windows - I don't know if it's been extended to keep up with the OSX enhancements.
The second option is an interesting project called GNUStep who are working towards a complete implementation of the NextStep API and have stated they will add Cocoa's extensions where they provide value. With it being open source you could always add any missing classes/functionality yourself.
This project is usable on FreeBSD and Linux and the core and gui classes are nearly complete however the developer tools themselves are not. This i not a problem however if you are developing on OSX and using them for a port.
[)amien
Microkernels being slow are the reason Macs are so much slower than PC's!
My PC runs a microkernel OS (Windows 2000), but I didn't notice any slow-downs when I switched from Windows 98.
Apple might have a proprietary OS in Panther but it is based on standards that allow for easy networking and integration into existing frameworks.
This is just an aside, and doesn't directly relate to MacOS.
For a long time, I used to think "standards good, propriatary bad". I wanted everything I used to be standards compliant.
Then I got into the industry, and ran into some of the standards-setting folks.
The good news is that generally folks involved with setting standards are reasonably (not necessarily the best) competent. It's not as good a situation as the brutally harsh meritocracy of Linux development, where code with vast amounts of time and effort can get thrown out because someone else came up with a better/faster system, but it ensures some degree of sanity.
However, politicking involved in standards committees is horrible. Generally, standards are set by industry consortiums, a recipe for disaster. Everyone has their personal pet features they want in, for starters. They then have to advance the interests of their company, so they try to exclude things that might benefit their competitors, and include support for things they're working on (even if they're technically inferior -- so if IBM is making a worse system than Dinky Company, Inc., it's likely that the technically inferior method gets used.). People are under pressure to finalize standards in time for products based on them to come out -- if there are still issues, too bad. Because different companies may prefer different methods of doing something/have different methods under work already, standards need to include support for both. Standards are frequently bad about exluding redundant methods of doing something. Finally, standards are frequently designed for companies doing a product implementation. They often cost money, and while complete they may not be particularly clear. This compares poorly against the RFCs that provide specifications for traditional Internet protocols today (yes, traditionally RFCs weren't final specs, but they are today).
I've come to realize that "open" is more important than "standardized". If you write a good specification for something, distribute it freely, and you've done a good job with designing the system, others can (and will) adopt the system (if it's better than the alternatives). yEnc, gzip and png were originally "open", though not standardized, and (perhaps more crucially) none were produced by industry consortiums.
May we never see th