japbike said:ya know, I really try to understand this and want to. But the further into this thread I got, the more lost I became. so all I have to say to that is, blah blah blah, I'm a dirty tramp...
how's Gentoo workin for u? any big issues uve come across with it?Hagios said:Gentoo, Debian, Slack, SunOS... You name it. But my favorite OS is OpenBSD.
Currently running 1 Gentoo box, one OBSD box, one SunOS box (Sparc20), and an XPPro box as my clientside machine.
Way I see it is, it's like rididng. Doens't matter what you use, so long as your head is on straight.
You must have one ODD NIC then because I've yet to see one you can buy off the shelf that wasn't capatible.BuRn__ said:i ran fredora core 1 on my laptop last year at college. and i ran SUSE9 on my laptop for a few months till i figured out my wireless pcmcia card isnt compatible :lame so i reformatted and put ::cough:: xphome ::cough:: back on it.
Q: I have read that Mac OS X uses the BSD kernel, but I have also read that it uses the Mach kernel. Which is it?
A: The Mach microkernel is the foundation of Mac OS X. (A brief introduction to Mach is available at Stepwise.) Mach provides basic hardware abstraction, memory allocation, process management (including threads), and interprocess communication. But Mach by itself is not a complete kernel. It does not provide device i/o, networking, file system support, high-level APIs suitable for application development, or many other services associated with a full-fledged operating system kernel.
Mach is designed to host these missing services on top of its platform-independent base functionality. The most common source for these services has historically been BSD Unix. The BSD subsystem implements the full set of APIs and services provided by BSD Unix, but it leverages Mach to perform memory allocation, process management, and so on. In an operating system with a real BSD kernel (e.g. FreeBSD, NetBSD, OpenBSD), the BSD kernel does all this heavy lifting itself.
When the BSD subsystem is implemented as a user-level process running on top of Mach, Mach is said to be a "pure microkernel." If the BSD subsystem crashes, Mach will not be affected. Many embedded systems use Mach (or some other microkernel) in this fashion to ensure maximum stability in even the most extreme situations. But pure microkernels have several drawbacks, the biggest of which is the performance hit incurred by the necessary (but computationally expensive) message passing between Mach and the user-level subsystem process.
Most modern desktop and server operating systems (including Windows 2000) use what is often called a "modified microkernel" architecture. Mac OS X does this as well. Instead of running as a user-level process on top of Mach, Mac OS X's BSD subsystem runs in kernel mode in the same address space as Mach itself. Most message passing between Mach and BSD is eliminated in this situation; the BSD subsystem can interact with Mach via normal function calls.
It's important to note that Mach's native kernel interfaces have not been broken by this "incorporation" of the BSD subsystem. They remain just as accessible to other subsystems as they would be in a pure microkernel implementation. This is important in Mac OS X because of the wide variety of subsystems implemented on top of Mach (and, by extension, on top of BSD): Cocoa, Carbon, the Java Virtual Machine, and even Classic.
Yes, this deviation from a pure microkernel means that Mach is vulnerable to BSD subsystem crashes. But if BSD goes down, Mac OS X is basically hosed anyway. There's no point in gloating that "Mach is still running just fine" when the machine is totally unusable (no device i/o, no networking == dead). This type of stability is important in embedded systems, but personal computers are useless without higher level services. And the performance boost from this arrangement is substantial.
As should be clear by this point, although Mach is the "real" kernel doing the low-level heavy-lifting, the overall "flavor" of the Mac OS X kernel is BSD. In Mac OS X, BSD provides the process model (process IDs, signals, and so on), basic security policies such as user IDs and permissions, threading support (POSIX threads), BSD sockets networking, and BSD kernel APIs.
Read that last sentence again, and note that this has nothing to do with a command line, a Unix-like directory structure, programs like "ls", "tar", or "gzip", or any of the other things often associated with BSD. Those things can be removed from Mac OS X without damage, and indeed may not be part of the default install. But "BSD" cannot be removed from Mac OS X any more than Mach can. Every process in Mac OS X is a BSD process. Every file has BSD-style permissions (yes, even on HFS+ volumes). Every thread is, at its core, a POSIX thread.
This pervasive BSD flavor may be why there is confusion about Mac OS X being "based on the BSD kernel." It's not; it's based on Mach. But Mach by itself does not a kernel make. The "officially blessed subsystem" running on top of Mach is BSD, but it is not "the BSD kernel." The BSD kernel manages its own memory and processes and does its own hardware abstraction. The BSD subsystem in Mac OS X uses Mach's implementation of these services. Finally, the BSD subsystem exists in the same address space as Mach for performance reasons, but this incorporation does not break any of Mach's modular interfaces.