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."
It's ironic that right after the story Technology Spending On The Rise, we get a story about how to run Apple software under a free OS.
Or is that, iconic?
Is this truly the only Earth I can live on?
So in plain English this means that Mac OSX programs will soon be able to run on BSD and eventually Linux?
You say things that offend me and I can deal with it. Can you?
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).
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.
Brennan Stehling - http://brennan.offwhite.net/blog/
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).
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.
http://tinyurl.com/4ny52
That makes absolutely no sense. Buying a copy of OS X is going to give you a CD full of code compiled for PowerPC, with no way to make any use of it on Intel sort of emulation. Darwin itself already runs on x86 hardware, so clearly the kernel is not the stumbling block.
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.
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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
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
IOKit points to drivers. So if someone crafts a driver for the Macintosh (popular consumer hardware platform, that), it should work:
... Remember, the existing Mac ports don't let you use Mac drivers any more than you can use Windows drivers on Linux/i386.
-On PowerPC machines running NetBSD, be they Macs or the few open PowerPC boards (AmigaOne, Pegasos) cropping up.
-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.)
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.
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.
Karma: Chameleon (mostly due to the fact that you come and go).
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
Sign #11 of Slashdot overdose: You see the phrase 'moderate Republican' and you wonder if that would be a +1 or a -1.
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. 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.)
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!
> These are serious questions. Who actually uses NetBSD? Why?
/usr/bin/* 2>/dev/null |grep NetBSD|wc -l /usr/bin/* 2>/dev/null |grep FreeBSD|wc -l /usr/bin/* 2>/dev/null |grep OpenBSD|wc -l
NetBSD is a stable, reliable, free, well-written, and administrator-friendly UNIX system. There are many reasons for running it.
> FreeBSD is stable and great as a Linux alternative.
So is NetBSD.
> OpenBSD is known for security.
This is what OpenBSD marketing claim, not the reality. OpenBSD web page claims one security hole in the default install for 7 years. They forget about 2 OpenSSH server bugs, one OpenSSH client bug, and 2 DNS client bugs. And anyway nobody uses an OS in its default install. Forget to apply the numerous OpenBSD patches and your system will be hcaked.
> NetBSD is multi-platform.
And as good for security as OpenBSD, and as good as a Linux alternative as FreeBSD is.
> So? Why would anyone want to use it? What has it really contributed to BSD? What has it really contributed to computing?
Many things actually. For instance, Apple claims that Darwin is based on FreeBSD. This is just untrue: they picked up the best known name in the FreeBSD world. Just peek at where the sources actually come from:
sh-2.05a$ ident
242
sh-2.05a$ ident
99
sh-2.05a$ ident
218
sh-2.05a$ uname -a
Darwin vip 6.8 Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC Power Macintosh powerpc
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".
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.
... Remember, the existing Mac ports don't let you use Mac drivers any more than you can use Windows drivers on Linux/i386.
:)
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.
-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.
Darwin is more than just the kernel, it's also the non-graphical userland. Darwin's kernel is actually called "xnu". And Darwin is licensed under the Apple Public Source License, version 2, which is actually GPL-compatible. They even worked together with the FSF to ensure this.
A monkey is doing the real work for me.
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
% ident -q /usr/bin/* | grep NetBSD | wc -l
120
% ident -q /usr/bin/* | grep FreeBSD | wc -l
191
% ident -q /usr/bin/* | grep OpenBSD | wc -l
203
% uname -a
Darwin ibook 7.0.0 Darwin Kernel Version 7.0.0: Wed Sep 24 15:48:39 PDT 2003; root:xnu/xnu-517.obj~1/RELEASE_PPC Power Macintosh powerpc
But yes, your point that Apple used code from a variety of BSDs is still correct.
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
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.
May we never see th
I don't think you can call it a MicroKernel when your web browser lives in kernel space....
It is specifically NOT GPL compatible. It is Free Software though. Check the GNU site for information about the status of the license.
Check Here
One Token Ring to Rule them All, One Search Engine to Find Them, One WAN to bring them in, and TCP/IP Bind them...
I'm not sure many people would want to go to court over it, but even assuming the EULA is legal, I'm not certain it's enforcable even if it's legit and users do have to agree to it (if you plug in an official Apple mouse, does that count as "running it on Apple-branded hardware"?)
You are not alone. This is not normal. None of this is normal.