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."
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
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 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.
I think you are being short-sighted here. A smarter and more realistic goal would be to get the compatibility with Darwin good enough that you could run Aqua and the rest of the OS X userland on top of NetBSD, without having to rewrite it all yourself.
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.
Actually, you can take all that wonderful BSD licensed code, strap the GPL on it, and redistribute.
The FSF calls the BSD license "GPL compatible" in that regard.
The unofficial
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.)
Hoping this is not a troll, but according to Mr. Stallman / GNU.org, the BSD license (well, 'modern', non-advertising BSD) is explicitly compatible with GPL:
# GP LCompatibleLicenses
http://www.gnu.org/philosophy/license-list.html
However, Vice-Versa doesn't work (GPL "trumps" the BSD-ness of the other work, since the BSD is so permissive on what is possible to do with the code).
Here's a quick refresher for anyone who doesn't "get" the GPL: Don't think "Free Software" (like gratis, non-paying). Think "Libre Software" (like freedom). This is also said: "Free as in speech, not as in beer".
But the GPL is *not* freedom for the programmer, it's freedom for the source-code. Straight from the GPL...
"""
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
"""
The BSD license basically says: "Do what you want, just don't sue me"
And a recommendation for all budding software haxors out there... GET COPYRIGHT OF CONTRIBUTOR CODE SIGNED OVER TO YOU (as project admin / fearless leader). The FSF requires this for all their sponsored projects, and it doesn't even have to be exclusive rights to the contributions.
Basically, once software is GPL, if you accept a typo-bugfix under the GPL, and don't receive assignation of copyright for it (not really, because of various "minor edits" stuff, IANAL), then the whole project (even if you're the 99% contributor and author of everything else) is forever and eternally available under the GPL, and you can't close it back off or change the license without *getting* that assignation of copyright (often stated: "the genie is out of the bottle").
From an individual project perspective, if you don't care about the code, use BSD (but remember that people can jack it and use it without giving you credit). If you want to make sure that the code you've written is always available no matter how it's used in the future, use LGPL (hey, *your* code is always available). If you have an agenda, go with the GPL (because GPL forces users of your code to also use GPL).
Honestly, pure GPL is really annoying a lot of times, witness the readline libraries. Want decent text-input handling? Boom, whole application is now GPL. My app doesn't deal with input handling, it isn't a text-editor. I (personally) consider input handling to be a "solved problem", but I can't use GNU-readline in my FooBar software v1.0 without releasing all my source code.
Personally, I usually don't have a problem with that, but I consider it most impolite to future programmers who want to use the bricks that I've built by stating: Even though you built this house yourself (using GNU/Brick 4.3), you still have to let me come in whenever I want and take a crap on those fancy toilet seats that you put in.
BSD => no restrictions.
LGPL => source code to your contributions (your bricks) will always be available.
GPL => use my GNU/library so I can crap on your new (GNU?) toilet seat.
Any questions?
--Robert
> 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
panther:~ $ ident /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
118
panther:~ $ ident
191
panther:~ $ ident
203
panther:~ $ uname -a
Darwin xynasha.local 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
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.
DarwinPorts will allow you to install ports from source, and appearently yum offers the ability to install binaries. The point being that Darwin is supposed to be a fully functional unix, not just the little bastard child that's kept in the cellar. Mostly useful I think when (as you pointed out) you want to keep multiple systems with identical configurations, or things that relate to administering or serving to os x machines, when you don't need the gui.
-- http://vectorvector.tumblr.com/
If you're going to run NetBSD ports, why not just run NetBSD and ensure compatability?
Well, I'm not a Darwin fan, so that'd be my answer, too. But the fact is, people *are* putting in the work so you can be guaranteed good stability on the other platforms.
After all, a 'port' ('source package' in NetBSD terms) is just a tarball full of source, a set of Makefiles to install it and register it for deinstallation cleanly, and any patches people have found to improve it for the particular OS. As far as I know, people can and do ship Darwin/IRIX/Solaris specific patches in pkgsrc, and it'll apply them as appropriate depending on the target selected.
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.
One of the major APIs for OS X already exists in an open-source form called are.
Of course, this is not emulation, rather source compatibility.
Throw in a GNUstep Makefile and new interface files, and you can have apps that compile from the same source on any free *NIX with GNUstep and on OS X with Cocoa.
Um, I use Darwin on an x86 as my primary firewall and work machine. You might be surprised to learn that unix does not necessarily require a goofy gnome foot dropping cores on your desktop every few seconds.
Um, folks use GNOME on Darwin on x86.
And while I don't use GNOME, it's matured a *lot* since the 1.0 days, and is pretty stable, so your jibes aren't exactly accurate.
May we never see th
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.
What alot of people are missing is that NetBSD runs on OLDER Mac's, it doesn't drop support for hardware just because its older that X years like Apple does.
So, if you've just become the proud owner of dropped hardware under MacOS X.N+1 you can load in NetBSD as the OS part, load in the MacOS X N+1 software on top of NetBSD and keep using your perfectly good older Mac hardware without the forced hardware upgrade Apple is doing for MacOS X itself.
THAT'S what so big about IOKIT support in NetBSD/ppc. The support of MacOS X software on older hardware that Apple doesn't want to support anymore.