OSNews

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.