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

So what's the implication here?

[numbski]

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?

Re:Plain English

[Anonymous Coward]

"So in plain English this means that Mac OSX programs will soon be able to run on BSD..."

Yes.

"...and eventually Linux?"

No.

Linux doesn't even support *BSD binaries yet, much less Darwin ones. And you won't be able to use NetBSD's implementation; software licensed under the GPL and software licensed under the BSD License can't legally rip code from each other.

Re:Plain English

[BrookHarty]

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

Re:Plain English

[Arker]

Actually, if I'm reading this correctly, it would mean running their libraries, containing those APIs, in binary form. There's your OSX on x86. Of course, it'll be slow as mud on that kind of hardware, but for those that keep screaming for it, there you go.

Probably breaks your EULA with Apple, if you agreed to one. And their lawyers would probably come down on you like a ton of bricks if you tried redistributing them, but for however many folks have an OSX disk, want to run it on x86, and didn't agree to any EULA, it could be amusing I suppose.

Re:Next stop, Quartz... then Aqua

[minus_273]

hmm OSX runs on a free OS already ; Darwin. goto the dev site and download the code. This is a pretty pointless project aside from the "cool hack" nature of it. There is really nothing new that can come out of it since you are just going from one unix on PPC to another and they are both free

Why I find this interesting

[Stonent1]

As the Mac OS series moves on, certain hardware is eventually dropped. This may be their only chance to keep their system going with something current. Also it adds the possibility to use any NetBSD supported PCI cards on your Mac.

This reminds me of Theo talking about running SunOS (68k) binaries on really fast 68k hardware supported by OpenBSD.

Re:ah, so THAT's the point! (RTFA):

[numbski]

I follow you now...uber_cool device gets released for Macintosh. Specialized device, no BSD drivers written.

IOKit allows these drivers to work on NetBSD/PPC.

Nice.

Re:Next stop, Quartz... then Aqua

[IM6100]

Actually, that isn't the case at all.

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 /etc structure on your i386, sparc, sparc64, macPPC, prep, m68k, etc. boxes.

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.

Enlighten Me

[use_compress]

Why would you want to X and one of its clumsy window managers instead of Aqua, the best user interface around?

Re:Enlighten Me

[Anonymous Coward]

XDarwin is a test case. The real goal is Aqua.

Re:Enlighten Me

[0x0d0a]

Because Aqua is mind-bogglingly inefficient and *isn't* the best user interface around. In Apple's golden days, yes, they could claim the best user interface around. However, they lost that claim over time, lost a lot of their HCI people, and now make something that looks like Enlightenment -- emphasis on eye candy over usability.

I've watched people using Aqua and a ton of other interfaces. About the fastest you'll see anyone is when they're using a fully keyboard-driven interface and are extremely familiar with the particular application they're using. Secretaries with DOS WordPerfect are a good example. A lot of crufty UNIX people with console or minimal X setups and a ton of automation crud they hacked up also fit in this category.

Mac OS X users rank among the *slowest* users I've ever seen use a user interface. There's lots of waiting and watching as things shift and move around and fade in and out and applications start up. This may be partly due to the fact that many OS X users use laptops, and are stuck with a trackpad, which significantly slows them down.

All the visual effects make sense *if* they improve coordination. For example, it may be "worth" a half-second of zoom animation if the extra half second avoids two seconds of a confused user trying to figure out where a new window came from -- this is the sort of mentality that drove the introduction of ZoomRects on classic Mac OS. However, I just don't see the kind of delay after doing something with a window.

I have Windows-T on my keyboard (Linux/X11/sawfish) set up to launch a new terminal in my home directory. Frequently, I whack that combination and start typing immediately. There is no input-device-changing context switch time, there is no waiting for the program to launch, and there is no time required to consult the contents of the screen.

Re:Plain English

[Anonymous Coward]

> Why not use MOL (Mac On Linux)?

There are some anwsers about this here

"Well, MoL is much like the PowerPC equivalent of i386 software such as VMWare or Plex86: these are virtual machines inside which you run the whole foreign OS, kernel included. It's like another machine inside your machine.

Binary compatibility makes it possible to run the foreign OS binaries on top of the NetBSD kernel. It is possible to mix binaries from NetBSD and the emulated OSes: they are able to communicate through pipes or sockets, you see them in the process list with ps, a foreign OS binary is able to launch a native process, and so on. Binary compatibility enable me to run an anti-virus software build for Linux as a filter in my NetBSD mail server, for instance. "

What this really means...

[Anonymous Coward]

I posted this in a thread above, but only one person's noticed. I hate to whore, but really, many of the comments lack perspective on the situation overall.

So if you appreciate this, please do whatever Slashmojo it takes to make it visible, or do the same for the original?

---

IOKit points to drivers. So if someone crafts a driver for the Macintosh (popular consumer hardware platform, that), it should work:

-On PowerPC machines running NetBSD, be they Macs or the few open PowerPC boards (AmigaOne, Pegasos) cropping up. ... Remember, the existing Mac ports don't let you use Mac drivers any more than you can use Windows drivers on Linux/i386.

-Hopefully with a simple recompile on NetBSD i386/etc. So for companies that have the sense to open-source their drivers, this is a shortcut to using them on NetBSD without rewriting the code itself for a new API.

Niche, but a nice hack, and with XDarwin working, also a convenience for PPC users if they come across a plain X11 app only available as a Darwin binary. (Rare now, but we don't know how it'll play out; look how annoying the Macromedia Flash plugin makes life on FreeBSD/i386; it's only distributed as a Linux binary, so you need the 'Linuxulator' to take advantage.)

---

Yep. As others have pointed out, it's also a shortcut to letting the Quartz server binaries from OS X run on NetBSD/PPC (just like X11 needs to be built to talk to the hardware through standard UNIX APIs or direct rendering modules, Quartz needs to be able to talk to the hardware through IOKit), but Apple's EULA probably bars that, so I don't see that as bragging rights. Drivers are third-party code, so they're not governed by Apple's licensing. :)

However, there may be a loophole - as I understand Apple's EULA, they don't care what you do with the software, as long as you only run it on their hardware. So Mac-on-Linux, which is more of a VMWare type deal, is perfectly legal under Yellow Dog or whatever -- *if* you're running it on Apple hardware, and have a license for your seat of OS X -- and Quartz atop NetBSD should equally be fine. (It could even be useful, depending on your opinion of NetBSD versus xnu [apple.com]. I gather a few people actually use Linux+MoL for improved stability; NetBSD+COMPAT_DARWIN+Quartz would offer the same, but with even fewer virtualization overheads.)

However, since Apple doesn't sell any version of OS X permitting use on non-Apple hardware, users of the new 'alternative' PowerPC boards are left out in the legal cold. (In the USA; if you live in a jurisdiction where EULAs don't hold and software is sold on copyright alone, go wild... but don't expect Apple to tolerate it any more than Microsoft tolerated DR-DOS or post-partnership OS/2.)

---

Okay, new content for this post: Can we stop arguing subjective things like package managers? It's a great distraction from the real issues in this thread. To lay that one to rest... well, let's put it this way - you can use the NetBSD pkgsrc collection on Darwin if you really want to. Choose your poison based on the kernels, not subjective nonissues with userland.

Re:Plain English

[mitch0]

That's a nice idea. Unfortunately it doesn't work. In reality, a lot of duplication of effort is done becouse of GPL libs (like readline), since the choice is almost never to make the whole bunch GPL, but to rewrite the necessary bits (usually under a BSD or other "free" license).

oh, well...

cheers,
mitch

Re:Plain English

[aminorex]

> > The PPC is a far better designed chip, of
> > course,

> By what do you base your claims on?

I make a similar claim. I base it on
experience writing assembly code and
compilers to assembly code for both
architectures.