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."

Comments

Plain English

[randomErr]

So in plain English this means that Mac OSX programs will soon be able to run on BSD and eventually Linux?

Only apps without Aqua

[Offwhite98]

The apps which will work will be the ones that only use the BSD core and not the entire Aqua graphics layer where the majority of popular MacOS X application run. But it is conceivable that an emulation of Aqua could be created for NetBSD which could replace X11. And since X11 is really show its age, I think a replacement for the graphics layer on Unix-like system is long in coming. Emulating the Dock and other MacOS UI features would be great. Just ask the developers at WindowMaker.

XDarwin and NetBSD/powerpc binary compatibility

[ubiquitin]

Although the post by Emmanual Dreyfus indicates that XDarwin is essentially a test case, this is a rather important test case. If you can run XDarwin, you're just a short hop away from having all of the X11 apps along with it. Also, imagine a package system like the fink working equally well on OSX and NetBSD. You could develop on OSX with its comfortable GUI and deploy to NetBSD with its comfortable price.

Re:Here's the point!

[Arker]

Apple won't port OS X to i386 so we'll do it for them. That's the point. Even if we have to buy a copy of OS X and hack the install, we'd still be able to run it on i386. That's the point, and a damn good one if you ask me.

Knock yourself out, but I can tell you right now that it won't be nearly as impressive as it sounds. X86 cpus really look bad when they try to emulate PPC/SPARC/Alpha and the like. You'll be a hell of a lot better off just buying a PPC box.

some posts here are crazy..

[minus_273]

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 :)

Re:Next stop, Quartz... then Aqua

[johram]

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.

I keep seeing this, and I keep laughing

[FredFnord]

Funny, I thought BSD's popularity was skyrocketing.

After all, all those MacOS X boxes... 3% market share... millions of people... plus, since Macs from back in 1998 can run the latest version of MacOS X (I'm typing on one now), and lots of people do that, probably significantly more than 3% of the installed base.

BSD sure isn't in any danger from where I'm standing, although who'd'a thunk that Apple would be its saviour?

-fred

Re:Next stop, Quartz... then Aqua

[anarkhos]

Aqua isn't a library. It's a specification nobody seems to follow.

Quartz isn't necessary to run most Carbon apps. I'd start there.

Standards not always good

[0x0d0a]

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.