[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Yes and no...
Mach Kernel pieces: Processor resources, scheduling, memory protection
BSD Kernel pieces: Process model, basic OS security, threading, Posix
I/O kit pieces: VM, Hardware drivers, multiprocessor management
BSD subsystem: common unix programs, shells, etc.
<a rel="nofollow" href="http://developer.apple.com/documentation/Darwin/Conceptual/">http://developer.apple.com/documentation/Darwin/Conceptual/</a>
It's not for nothing that their mascot is a duck-billed platypus with a
trident and holding a devil hat. :-)
>> The Unix emulation is
>> through the FreeBSD / NetBSD mish-mash OS personality which rides on
>> top of
There's something of a semantic problem, I think, when trying to
discuss OS X's core OS pieces in comparison to forms of linux, and for
that matter, NT. Using concepts like "above" or "on top of" can be just
as misleading as saying "side by side with". Mach is a microkernel that
is fairly useless without an additional set of software components, as
compared to a standalone monolithic (or modular) kernel.
One metaphor I like to use is to imagine the linux kernel being written
by two (or more) totally separate teams, with each team taking
responsibility for separate areas. Are the linux developers who work on
the team that does process management merely creating an "emulation" of
process management "on top of" the other team's work? I suppose in some
senses they are, and in other senses, they aren't.
>> To me, it's not appreciably different than installing Cygwin on NT and
>> calling that "Unix on the desktop"
Well, NT without cygwin is usable as a standalone OS (well, ok, some
folks don't find NT usable, but run with me here...). The OS X Mach
kernel without BSD is not really usable as a standalone OS.
I'd argue that is an appreciable difference. :-)
Extending that thought, the OS X desktops and application API's (Cocoa,
Carbon, Aqua, and even Xfree86 to some extent) *are* a bit more like
cygwin on NT. There's a usable OS underneath without adding those
additional pieces to extend the available features of the system.
>> .... Neither really are, or are "desktop
>> Unix done right" --
Unix is simply not a desktop OS. The API and GUI stuff OS X runs on top
(Aqua, Cocoa, Carbon) of it's core OS are what makes a OS X desk-toppy,
>> they're both command-line unix-like worlds (for the most
>> part, though some aspects of both OS X and cygwin's Unix layer are
...Spooky even. :-)
>> side-by-side with basically separate, non-integrated, non-Unix GUI
Well, to re-iterate, an NT box can work (again, "work" is being used
loosely here) without cygwin. BSD, OTOH, is so closely tied
(integrated?) to the Mach microkernel on OS X, that OS X simply cannot
functionally work without it. (The aqua (graphical) layer of OS X,
OTOH, isn't really needed.)
>> *shrug* I'm not sure what a really graphical desktop-oriented Unix
>> look like (or if it's possible -- how do you GUI an inherently
>> textual OS?),
>> but OS X ain't it, IMO.
I like OS X because it gives me, in linux terms, "a really sweet window
manager, and has a hardware and software environment that is closely
knitted and tuned to work well together". It has enough unix-on-desktop
features to cover my needs, but as far as non-desktop server features,
I'd be loathe to port most of my server apps to it,
3rd-fastest-supercomputer-in-the-world rank not withstanding...
<a rel="nofollow" href="http://www.top500.org/list/2003/11/">http://www.top500.org/list/2003/11/</a>
As far as a "desktop-oriented unix", I'd agree that not only is OS X
not the holy grail, I also think the whole concept is a bit bizarre.
Desktops are single-user machines, so process management would have to
be cooperative (or user driven in some other way). The GUI interaction
is more important to the user than background OS work, so the GUI layer
should be as close as possible to the OS for speed reasons..... Keep
adding up the features that make make for a great single-user box, and
all the really great features of unix-y OS's gradually get thrown out
the window, and we're left with monstrosities like, oh, Mac OS 7 or
It's sort of like trying to make "a practical single-user 747", or even
"a personal aircraft carrier".
> I am starting to wonder if migrating OS X to Linux makes sense. With
> introduction of the Linux 2.6 kernel, and the scalability and security
> enhancements, I wonder if Apple might consider using the Linux kernel
> instread of the Mach micro kernel?
Highly doubtful, for licensing, massive re-porting, and CPU
optimization reasons. :-/
....I'd guess that it'd be about as easy as porting NT to a linux
kernel (or vice versa). They're that different.
> From a raw resource perspective, Apple
> would gain the development efforts of thousands and thousands of
> developers, though porting it would prob take time.
Those thousands and thousands of developers aren't all buying apple
hardware for PPC flavors of linux, and if they were, they could just as
well contribute to darwin, which is also an open-source unix
project.... :-) Also, the current raw development efforts on linux
(IMO) aren't really highly focused in areas that make sense to apple's
business model, i.e. selling more apple boxen.
For some much more detailed arguments on the whole issue, surf any one
of the million threads on why apple won't port OS X to X86, which is
analog to why apple has not interest in supporting directly competing
OS and hardware technologies.
> Has anyone studied the
> Mach kernel?
(Tentatively waving hand...) The mach micro kernel is a totally
different beastie than many other things called kernels (as you may
have guessed from the first link). I suppose the confusion that created
this thread might be linked to an assumption that BSD pieces (and I/O
kit) run *in addition to* the kernel, so people used to larger kernels
might be under the assumption that the kernel could run *without* any
additional BSD (or other OS flavor, Mach is not OS-specific)
> How does it stack up with other OSs on multiple procs?
Short, vague, not-very-technically-precise answer: It's sometimes a tad
slower CPU-wise than some other OS builds, which can be made up for by
getting faster/more CPU's and other hardware optimizations (mobo IO
channels, backplane throughput, etc.). Mach was built from the ground
up for the support of multi-processor environments and OS's, and
sometime suffers a bit on single CPU machines.
The problem with a longer, more technically precise answer is that the
Mach micro kernel itself isn't actually responsible for multi-processor
management, that's the responsibility of other pieces. As a kernel, it
doesn't do a whole lot of things that folks with a history of working
with larger kernels would expect a kernel to do.
<li><strong><a name="00016" href="msg00016.html">[ale] OT: Re: posting to Linux mail list</a></strong>
<ul><li><em>From:</em> tfreeman at intel.digichem.net (tfreeman at intel.digichem.net)</li></ul></li>
<li><strong><a name="00030" href="msg00030.html">[ale] OT: Re: posting to Linux mail list</a></strong>
<ul><li><em>From:</em> kaboom at gatech.edu (Chris Ricker)</li></ul></li>
<li><strong><a name="00008" href="msg00008.html">[ale] OT: Re: posting to Linux mail list</a></strong>
<ul><li><em>From:</em> matty91 at bellsouth.net (matty91 at bellsouth.net)</li></ul></li>
<li>Prev by Date:
<strong><a href="msg00010.html">[ale] OT: Re: posting to Linux mail list</a></strong>
<li>Next by Date:
<strong><a href="msg00012.html">[ale] smbpasswd error</a></strong>
<li>Previous by thread:
<strong><a href="msg00039.html">[ale] OT: Re: posting to Linux mail list</a></strong>
<li>Next by thread:
<strong><a href="msg00016.html">[ale] OT: Re: posting to Linux mail list</a></strong>