Hash: SHA1

Lonnie Cumberland wrote:
> Greetings All,
> I really appreciate all of the feedback and reply posts regaring my
> inquiry about Darwin and FreeBSD.
> I am still somewhat confused as I have been looking at FreeBSD which I
> think is VERY good and have also recently been able to boot up the
> OpenDarwin 7.2.1 as well, but never could get the Darwin 8.1 cdrom to
> install.
> If I follow these messages correctly then it appears that FreeBSD is
> just as good as Darwin although I had expected that the inclusion of
> the CM kernel integrated with the FreeBSD kernel along with various
> other improvements would have made the Darwin software better.
> One thing that I can tell at the moment is that the FreeBSD OS seems
> to have better support for hardware since Darwin (Apple) if very
> specifically targeted to chosen hardware and also they seem to use
> these Carbon libraries for getting things to run which I do not kow
> where to locate more information on them.
> We were looking for a good OS to build from and now know that it will
> not be Linux, but on the BSD side of the house as I like what I have
> seen in both FreeBSD and also what little I have seen in Darwin.
> I would still like to do some more testing to get a better feel for
> what Darwin can offer, but the bottom line is that all of these are
> directly related to FreeBSD and are stable and fast compared to other
> non-FreeBSD related OS's.
> Thanks again and have a good day,
> Lonnie T. Cumberland
> OutStep Technologies Incorporated
> "Open Source...... opening the doors for the future in the world of
> today...."
> On Mon, November 13, 2006 08:38, David Kelly wrote:
>> On Mon, Nov 13, 2006 at 01:28:16AM -0800, Ted Mittelstaedt wrote:
>>> No, they used it all as the Darwin core.  Then they took Darwin and
>>>  added their own GUI (used to be called Aqua) and that is MacOSX.
>> X11 also comes on the MacOS X DVD, but is not installed by default.
>>> Bear in mind that the MacOS X gui does not translate directly into
>>> UNIX.  For example, you can load MacOS System 7 files with a
>>> separate resource and data fork onto MacOSX.  The MacOS X gui
>>> handles a lot of this kind of stuff.
>> I lost you there. "So what?" The classic Mac file format is more
>> advanced than a Unix (or Windows) flat file. The MacOS X Unix view of
>> such files is morphed into a directory of files. The GUI turns such
>> directories into a single application icon which *can* be opened to
>> see what is inside but normally a double-click or open launches the
>> app.
>>> Apple also doesen't use the UNIX security model.  As near as I can
>>> tell their core security model is an ACL model not a user/group
>>> model. Once again this is something that's handled elsewhere.
>> Don't know how its done underneath but from a shell and ported
>> applications it looks exactly the same:
>> [EMAIL PROTECTED] {767} uname -a Darwin dot-matrix.local 8.8.0 Darwin
>> Kernel Version 8.8.0: Fri Sep  8 17:18:57 PDT 2006;
>> root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh powerpc
>> [EMAIL PROTECTED] {768} id uid=503(dkelly) gid=501(dkelly)
>> groups=501(dkelly), 81(appserveradm), 79(appserverusr), 80(admin)
>> [EMAIL PROTECTED] {769} who am i dkelly   ttyp2    Nov 13 08:17
>> [EMAIL PROTECTED] {770} ls -ld . drwxr-xr-x   33 dkelly  dkelly  1122
>> Nov  1 13:30 .
>>> The biggest problem with MacOS X is that a lot of UNIX software
>>> that runs on FreeBSD and such, is not ported to MacOSX, and it's
>>> very difficult to compile on MacOSX.
>> Really? Good thing I didn't know compiling was difficult. The other
>> day I wanted a MacOS X version of mkisofs. Copied cdrtools from
>> /usr/ports/distfiles/ off a FreeBSD machine. Built without a complaint
>>  in moments. Not terribly thrilled with its default install location
>> of /opt/schily/bin/ but at least its easy to remove.
>> --
>> ======================================================================
>> ==
>> Whom computers would destroy, they must first drive mad.

        Well, when I was in an interview with a Mac lead recently, he was
telling me that there were issues with processor affinity in the Darwin
kernel, meaning that processes/threads would jump from processor to
processor, instead of staying on the same processor. This affects all
machines with multiple processors (be they virtual or physical) from
what I understand, and it does generate a lot more relative delay in
multithreaded code as the amount of time it takes to fully change
processor state is higher moving from one processor to another, when you
have to move cached memory back and forth down the memory model, etc.
        Sad, but it's one of the current problems with the implementation of
the mach kernel-Darwin-over a monolithic kernel like FreeBSD's, Linux's
or Window's.
        Something minor to ponder over..
- -Garrett
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to