[ale] OT: Re: posting to Linux mail list

[Ronald Chmara]

On Jan 1, 2004, at 11:51 AM, matty91 at bellsouth.net wrote:
> On Wed, 31 Dec 2003, Chris Ricker wrote:
>> On Sat, 20 Dec 2003, aaron wrote:
>>> As I believe I have pointed out before with info like...
>>> <http://developer.apple.com/unix/index.html>
>>> ...there is nothing of "emulation" about it. The integral, low level  
>>> FreeBSD
>>> Unix layer handles the overwhelming majority of OSeX network  
>>> interaction and
>>> program API's. The full FreeBSD kernel (currently FreeBSD 5 with  
>>> OSeX Panther
>>> 10.3.x) is about as far from "rudimentary" as it gets.
>>
>> Not really. All your basic OS functionality (memory management,
>> multitasking, scheduling, etc.) is provided by Mach.

Yes and no...
Mach Kernel pieces: Processor resources, scheduling, memory protection
BSD Kernel pieces: Process model, basic OS security, threading, Posix  
APIs
I/O kit pieces: VM, Hardware drivers, multiprocessor management
BSD subsystem: common unix programs, shells, etc.

See:
http://developer.apple.com/documentation/Darwin/Conceptual/ 
KernelProgramming/Architecture/chapter_3_section_3.html#//apple_ref/ 
doc/uid/TP30000905-DontLinkChapterID_1-TPXREF102

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
>> that.

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,  
IMHO.

>>  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  
>> just
>> weird)

...Spooky even. :-)

>> side-by-side with basically separate, non-integrated, non-Unix GUI
>> worlds.

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  
>> would
>> 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...
http://www.top500.org/list/2003/11/

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  
Windows ME.

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  
> the
> 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)  
components.

> 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.

-Bop