A lot has been said about the roots of Mac OS X and there is quite some confusion about its exact Unix geneology. We asked Jordan Hubbard, engineering manager of the
BSD Technologies Group at Apple and one of the most important figures throughout the FreeBSD history, about the older releases of OSX, the current one and the future ones, and this is what he replied to us: “The earliest releases were based on FreeBSD 3.2 and NetBSD, though I’m not as clear on what version of NetBSD was used. For 10.2, we did a massive re-sync with FreeBSD 4.4 and 4.5 and regard FreeBSD as the primary reference code base going forward.” Update: Read for some more clarifications from Jordan. Update 2: More updates from Jordan! Read on.“The fact that we’re based on FreeBSD does *not* mean that Mac OS X has any plans to sync up with FreeBSD 5.0 or that the SMP or multi-threading work there will necessarily have any bearing on Mac OS X. Mac OS X has its own Mach-based threading and SMP mechanism already and this mechanism is orthogonal to what FreeBSD is doing. Where the greatest amount of sync-up will be occurring is likely to be outside the kernel.”
“[…]It’s also amusing to see the semi-coherent reply
that I didn’t do any engineering for FreeBSD when I wrote the installer, the package tools and the ports collection. 🙂 In any case, Mac OS X’s primary interest in FreeBSD will always be in the -stable branch and when 5.x goes -stable, I’m sure we’ll look into any opportunities for merging in work on UFS2 or some of the advanced networking features. I just wanted to correct your first assertion that we’d be primarily interested in the SMP and multi-threading features of 5.0. Also, the folks who refer to Mach as “old technology” clearly aren’t familiar with the fact that Apple has done a lot of work
on Mach since its inception, not least of which were the improvements originally done to make mkLinux a reality.”
I don’t think the changes to the FreeBSD kernel change much in xnu, Darwin’s kernel. Darwin doesn’t even use FreeBSD drivers.
The lowest level changes which are common would probably the TCP stack and up.
Hubbard was an important person in FreeBSD history although never as an engineer. I don’t think his position at Apple could be technical either. (Perhaps that’s why he does not know which NetBSD code was used)
Regarding revolutionary stuff in FBSD 5, it just does not make sense.
First Nubbard himself in an earlier interview he tried traitorously downplay inportance of 5.0 as milestone on the path to a multithreaded OS.
Second, Mach was design as multithread with MP support, thus nothing from 5.x will be revolutionary for OSX. Because regardless of what Hubbard says OSX is based on first on Mach then on anything else.
Reality is 5.x update to BSD server could slightly help with overall BSD layer’s contention, but probably not much more than that.
Eugenia, what happened?
I asked Jordan, and I include this reply in the story.
> Mach was design as multithread with MP support, thus nothing from 5.x will be revolutionary for OSX.
I would not call the OSX *truly* multithreaded. It is not as responsive as it should have been in a real multi-threaded environment. Use BeOS and then we talk again.
> OSX is based on first on Mach then on anything else.
Maybe they are trying to change this with the addition of NetBSD and FreeBSD code. Mach is not what I could call a modern design anymore.
Here’s two interesting links :
1) http://www.opendarwin.org/faq.shtml#lineage
2) http://perso.wanadoo.fr/levenez/unix/
Ludo
—
http://islande.hirlimann.net
It just seems that in the beginning they were using OpenSTEP/Mach, then they added some code from NetBSD and FreeBSD 3.x, and now they are going fully with FreeBSD.
I think this clears it out pretty well.
jhk designed/coded the ports system.
>I would not call the OSX *truly* multithreaded. It is not
>as responsive as it should have been in a real multi-
>threaded environment. Use BeOS and then we talk again.
I’ve used both on similar hardware. I ran beos on PPC bebox, and run X on Dual 450. Yes beos was reponsive, yes X is not. But then again I never had a usefuyll App on beos because of it’s threading mechanism, the API is C++ only so no-one can code BeOS apps without being specific. X can be accessed in C/C++/Objective-C and *should* be available trhu carbon in pascal.
>Maybe they are trying to change this with the addition of
>NetBSD and FreeBSD code
NetBSD code is mainly for utilities. FreeBSD lies in the socket code, because socket is the stanadrd way of networking trhu TCP/IP, Mach’s messaging system is not and no-one knows how to use it so porting apps would have been uneasy.
Because regardless of what Hubbard says OSX is based on first on Mach then on anything else.
This isn’t true. XNU is not Mach-like at all in the traditional sense. There are no Mach servers… the kernel is highly monolithic. XNU also utilizes BSD signaling. The Mach components of XNU are in the process/thread management and VMM, as well as Mach messaging.
Reality is 5.x update to BSD server could slightly help with overall BSD layer’s contention, but probably not much more than that.
There are many features of FreeBSD 5 I’d very much like to see in XNU. These include but are not limited to:
UFS2
kqueues
POSIX4 realtime and asynchronous I/O
I believe thinking of XNU in terms of BSD components and Mach components is flawed. When you look at things like the UBC and so forth, XNU really is a true hybrid kernel, and that’s the best way to think of it, as something different from Mach and BSD but which borrows on both.
>I think this clears it out pretty well.
Mach won’t go away it’s Mach that permit IOkit (Darwin/ X) is the only os where you have to code your drivers in c++ which is good because driver development will take less time if your driver’s family has already been created which is the case for Video cards, SCSI Cards and many others.
>OpNSTEp
is BSD 4.3, 4.4 + display postscript
Oof, c++ seems awfully heavy weight for doing just drivers.
You definitely want the full control that ‘c’ gives you.
c++ just throws in way too much extra “hidden” stuff. What’s so hard about doing function pointers?
If FreeBSD is really so great, why wouldn’t one choose it over OS X for their servers?
If I’m not interested in any of Apple’s server technology (like WebObjects), why should I switch? FreeBSD is, of course, free and x86 hardware is so much more affordable.
Sure it’s the nicest *nix desktop out there, but I don’t really need or want to run things like Photoshop on my servers.
This isn’t to attack any OS X users out there…I’m just curious.
Over and out.
-a
Good question! I puzzled over that one for months
What I worked out is this – If you’re the type who builds a machine and can administer it in your sleep, you won’t sleep. If you are someone who needs to administer a bunch of machines (small lab, big lab, classes/school, company, etc.) and isn’t a sysadmin, it’s for you. You don’t have to grab tools and compile them – you might not know how.
You have consultants and support staff ready to help, pretty much as part of the package. You don’t have to worry about remote machine maintenance. Heck, you can boot each machine from a trusted image-file somewhere behind a firewall, restrict access to whichever apps you want on a per-user or per-machine basis and never have to see the command line. You can plug in a bunch of machines, airport or wire ’em together and they see each other. No network config or anything.
It’s for the ease-of-use for folks that *aren’t* here on OSNews entirely too often (like me
I actually use OS X Server a bit now, and I’m one of the biggest unix-ish snobs out there. I say unix-ish, ‘cuz most of my background is on the big iron (worked on the OS and C++ compiler teams at Cray – before the SGI buyout), and that ain’t UNIX 
Not even as much as X is. Close, though.
Peace,
‘Rithm
> Maybe they are trying to change this with the addition of NetBSD and FreeBSD code. Mach is not what I could call a modern design anymore.
I am sure who said that, was it Eugegia or Hubbard?
Either Mach is far more modern than any BSD clone.
Now OSX may not be truly multithreaded, but has nothing to do with Mach. Once could write whole buch of HOT locks on any multithreaded kernel.
It’s true XNU is hardly colocated implementation, but it is still OSF Mach 3.0 based since it shares all the original code low level services.
In fact only new feature I found was “working set” detection. I am not sure about UBC (Unified Buffer Cache), but even if xnu has ubc, it still needs to address whole bunch of more important VM issues.
As far as FFS2 it’s easilty portable and not need 5.x bringup. Asynchronous I/O is great feature. But I fail to what will kqueue do for Darwin?
God written c++ doesn’t have to be slower than c. Just be careful with inheritance and virtual classes/methods. Also stuff like implicit use of copy contructor can make your code crawl. if your functions/methods take an object as a param make sure they are sent as a reference or pointer for example. Remember, c++ is pretty much c with stuff added to it. You don’t have to use all the features of c++.
I think a lot of you are confused with what the real interaction between Mach and FreeBSD is. Mach contains all the hardware interaction, FreeBSD is the software interaction layer. All tools written on FreeBSD should not have much trouble being recompiled on OS X because the interaction with the OS is through a Posix OS based on FreeBSD.
Now if you need to interact directly with the hardware, i.e. something like a CPU monitoring tool, you need to communicate directly with Mach.
Oh and another, calling Mach old is rediculous. in the Unix would Old is good, it has proven it self. And take a look at the GNU Hurd development. That looks a lot like a new Mach to me…
I have been reading quite a bit on UFS 2, pretty sexy if you ask me…
Since Apple & Jordan clearly have a good understanding of what the upcoming sync up is going to be, why not just tell us?
Is there some sort of roadmap we can examine?
The history is documented in a reasonable format:
http://developer.apple.com/darwin/history.html
A simple timeline of future plans would help all developers support the Apple platform.
And on a Darwin sidenote, I am ever hopeful of an Apple switch to AMD Hammer or Intel Pentium/Xeon/Itanium:
Darwin on x86
Q: I must say that Apple is doing a really good job with their open-source strategy, and I’d like to congratulate you for trusting in the power of the community.
It would be great if you could give more attention on the porting of Darwin for the x86 platform (don’t let the guys who are doing that alone!), as it will help a lot on the rapid growing of the developer base, helping the development of the system and (of course) the development of new drivers, filesystems and other important components that could be modified to work also on the PPC side.
A: Thanks. Much of Darwin is processor-independent BSD code. We’re using the x86 platform as an integrity-check to help us make sure that the architectural underpinnings function just as well in Darwin as in the BSD code. This is important to maintain compatibility with the ever-evolving BSD software base, and also helps us to maintain a high-quality code base through the benefits of designing for software portability. We welcome new drivers and other components to help test Darwin on the x86 platform.
Q: Will Mac OS X be ported to the PC?
A: There are no plans to make Mac OS X available on any non-Apple platforms. We’re simply making Darwin, the underlying operating system of Mac OS X, a better system by using x86 as a test bed to ensure architectural soundness and to reap the benefits from applying portable software coding practices.
Always room for ray of hope in there. I would definitely purchase a more reasonably priced Intel/AMD Mac.
#m
On a sidenote, how comes some people tag FreeBSD always as server OS? It’s as much (if not more) an UNIX system as Linux is, and when Linux is useable on the desktop, so is FreeBSD.
Glad to have you aboard at the mothership – hope they aren’t working you too hard at the Fruit Factory.
I like OS X a LOT and Jaguar even more. The *BSD-ishness of OSX even convinced me to get rid of Windows and Linux and go FreeBSD the whole way – I’m not saying that FreeBSD is “better” than Linux, but just I find the CLI in BSD to be a more comfy fit. The improvements I’ve seen in Jaguar demos so far convince me we’re on the right track here – I’m moving to FreeBSD 4.6 on my PC at the weekend
As for Eugenia and her interminable references to Be. If people could buy it, then maybe people could see how responsive it was.