Slashdot Mirror
Mac OS Mach/BSD Kernel Inseparable
Anonymous Coward writes: "One of the more significant statements of the session [at Apple's WorldWide Developer's Conference] came when Magee told the audience that the Mach kernel and the BSD layer which lays upon it are inseparable. "Every application [that runs in Mac OS X] is a BSD application," said Magee. "You can't keep the system running without the Mach kernel and the BSD layer." This quashes the public rumour that Apple will be able to ship a "lite" version of Mac OS X which will contain only the smallest possible bit of BSD, or another that questions Apple reluctance to move its tools to Linux."
Remember, just because MacOS is a completely BSD-based system, doesn't mean you'll be able to tell it. Apple has stated that the Terminal won't ship with the OS, and you won't be finding very many Unixisms.
Of course, the first thing some of us will be doing is installing a terminal and maybe a few other things, and we'll have all the gooey Unixness that we need. But really, Apple has no interest in scaring off their core markets...
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com)
- Jeff
How long will it take before the gui interfaces, easy administration.. etc, is completely ripped off and used as a template of solid user interface design for unix. In something like kde/gnome/icewm
I just purchased a G4 for one of our graphics designers at my work and I must say
Anyways.. I hope that OS/X kicks some ass in the industry.. I hope that we can learn a lot from it. If it is everything that I hope it is.. (hehe).. I will probably be replacing my computer. BTW, does anyone know if this will spark more interest from the Adobe group to start portin their applications to Linux? (Should be easier with a BSD/Mach port already done...)
The thing that GNU/Linux can learn is a cleaned up and unified configuration system. To my mind the area where GNU/Linux really needs to clean things up is over in /etc (and maybe /dev and /var and a few of the other utilitarian filesystems). Create a unified, consistant and extendable XML setup for system, application and user configuration files.
/etc (as well as pulling in configuration files from elsewhere and giving them structure) is there to make things consistant. If anything it will be easier for those writing administration scripts to work if said configuration files are standardized and organized. Quite the opposite.
The main advantage here is that it allows for the creation of universal configuration tools that don't have to be recoded every time a new application comes out. Just plop in a new XML file (and possibly a DTD) and all of a sudden you've got a whole new application to manipulate easily. Not to mention developers have a nice little API for creating and managing configurations that allows system defaults and user overrides of said defaults transparently.
Little things like file bundles should be included in this restructuring as well. There are some nice nifty little bits in Mac OS/X. Apple really cleaned up some of the nastier bits of Unix when they tossed out historical precedents. Not that I totally agree with all of their decisions, but a lot of Unix simply evolved rather than was desgined coherently. It's time those parts were cleaned up. A lot of the usability issues with Unix are going to be stalled until they are.
Note that this does not mean babyfying Linux in any way. The thing with file bundles is you can open them up if you want granularity. Going to XML for all the configuration files in
I'm using GNU/Linux here because some things are handled at the kernel level but a large chunk of it is in the GNU tools that are traditionally bundled with Linux. Both need some modification here to come up with a coherent and unified system.
Migration is going to be a nightmare (remember glibc?) however once migration is done things can really start to move forward in terms of usability. The GNOME/KDE people would love to be able to set up pretty GUI-based configuration tools to manage everything, and the Perl/Python people would be in heaven because they could write real libraries to manipulate those things (not to mention all the people who use those libraries).
Backwards compatibility is all fine and well, but we all know of how backwards compatibility can drag back progress in the computing world. This is one of those cases where things have reached the point that areas need to be scrapped and rebuilt in the name of future progress.
While that may be true for many Mac users, I think you'll find those of us who have been working on them for as many years as you have been working on a PC are as competent on our OS as any Linux guru is on Linux.
Having been using a Mac for 10-12 (I stopped counting after 7) years, when I decided to build myself a PC and install Linux on it, want to know what the only problem I had was? Didn't seat the RAM correctly so the computer beeped when I turned it on.
If you want to talk about some Mac users, fine. But don't slight all of us because there are quite a few gurus.
Now, if you're talking about Mac users coming to Windows or Linux, geez! Windows is nowhere near as intuitive or consistent as a Mac, and it does take people some time to get up to speed.
As for Linux, there's a definite learning curve. If you don't believe that, you're deluded. But I'm a Mac user, and GEE, I figured it out. I'm posting this from Linux.
Go back to your AC hole or limit your statement to the _subset_ of Mac users who are thick fuckers. And compare the size of that subset to the _subset_ of Windows users who are thick fuckers.
And finally, recognize that when it comes to Linux, most all of us were thick fuckers when we started; the difference between us is how long it took to understand it all.
Let me guess, you think it's a good thing if people had to spend 10 minutes poking under the hood messing with stuff just to start their cars, right?
... But the people I supported, albeit without any real computing knowledge, were some of the smartest people I've ever known. Lack of computing knowledge has no bearing on someone's intellegence or lack thereof.)
Some people are more interested in getting work done than fucking around with machines that should be there to serve them instead. I personally have no problem screwing around with the innards of my OS, writing shell scripts, and so on. But should my mom be forced to? I certainly don't think so.
To call people names simply because they want to get work done - the original intent of computing technology - rather than make it a hobby is pretty arrogant.
(And yes, I've worked tech support in the past and have had a lot of laughs
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com)
- Jeff
This is not flamebait or a troll, but it is somewhat unkind to (current) Macs and other popular views. Deal with it.
Up until now MacOS has had a good GUI only. The OS itself hasn't been very powerful. On the other hand, the various Unices have been the exact opposite. Windows has been a (not-so-)happy medium.
So what happens when you put a good GUI on top of a good core? The obvious answer is: You take over the world. But what if you don't? That is, what if the real power of Unix is the combination of power AND the know-how of the people who took the time to learn it?
If this happens, will we finally see an end to the countless "GUI for Linux" projects (not to mention advocates)? Or will these people never admit that a computer isn't like a car? (Cars provide a linear service--travel. Computers provide a non-linear service--emulation of any machine [in the mathematical sense]).
If we look around at the non-computing world, do we see any simple AND powerful products in the hands of Average Joe? (A CD player is more advanced than a record player--but is it more powerful?) I can't think of any...
I think the reason for this is clear: Powerful devices require thought. Simple devices are designed to not require thought. These goals don't mesh very well.
Understand, though, I'm not saying "any GUI is a bad GUI" and I'm not saying "you can't get better than [cli|X|whatever]". I AM saying "Beyond a certain point, GUIs enter a region of tradeoff between power and simplicity. What is that point and how will we know when we've reached it?"
--
Have Exchange users? Want to run Linux? Can't afford OpenMail?
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
To recap: the underlying MacOSX operating system is Mach 4.4, which is bsd based, and (believe it or not) does *not* use the Mach microkernel. Ask Avie Tevanian if you have to. Mach ideas, microkernel ideas, but not the Mach microkernel.
This operating system has clever copy-on-write VM features and other things that mean that on some tasks it is severely performant.
The Darwin project is distinct from MacOSX.
To the best of my knowledge, Apple have never had any plans to ship their "tools", whatever they may be, on any but a few platforms -- MacOSX, and Win32 with some compatibility stuff running. The Win32 products appear now to be destined to become only a development platform for WebObjects. WebObjects deployment code, as distinct from the WebObjects or MacOSX developer tools, appears to be going highly-crossplatform with the pre-announcement of a pure-Java-only WebObjects5; but this has nothing to do with MacOSX.
Apple appears to remain committed to opensource development of Darwin, and the bsd-layer CLI stuff which will be common to MacOSX will presumably be opensource and kernel-independent.
Terminal.app will almost certainly ship with MacOSX; but probably as an optional administration package. Apple remains committed to a MacOSX in which the user need never see a command line unless they want to.
---
No. But by the same token, those people who want to screw around with the innards should not be prevented from doing so.
---
Of course not. And there have been plenty of Mac users who have screwed up their machines in the process of learning the voodoo that is ResEdit.
But in the end, there are different operating systems for different people. Some are better for those who don't want to poke around (MacOS), and some are better for those who do (Unix/Linux).
That's why MacOS X should be so interesting - can Apple pull off both, making an OS simultaneously intuitive and usable for the masses, while still giving tons of power to those who want to customize their experience? Maybe, it's hard to say. I have used recent developmental versions of OSX and yep, the shell and everything it entails is still there if you want it.
I have some issues with the new UI (Dock sucks, lack of Apple menu, etc) but it has some time for improvement. I can imagine Unix/BSD types swarming over it and making a pretty good high-end user environment, though...
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com)
- Jeff
So why did NeXT use Mach in the first place? I'm speculating again. I guess they started out from OSF/1, and the OSF/1 developers had your goals (a) and (b) in mind.
Remember: The Open Software Foundation (OSF, now a merged with the Open Group) was a group of vendors that wanted to develop an Unix platform independent from then-AT&T's UNIX. OSF/1 was to be their kernel. DEC used it to build DEC OSF/1 (now Compaq Tru64 UNIX or whatever it is called this week), and I guess that NeXT took it to build NeXTStep.
The first version of OSF/1 (the one out of which vendors made successful products) was a BSD single server on top of Mach 2.5. At the time it was developed, it was not yet well established that Mach-based systems are slow. In fact, the Mach-2.5-based OSF/1 probably was not that slow: Mach 2.5 had considerably less bloat than Mach 3.0, and it was not really a microkernel-based system as it was closely integrated with a BSD kernel - that is, the microkernel and the BSD server shared the kernel address space (this is sometimes called ``colocation''; the OSF recently rediscovered this technique to speed up MkLinux on top of Mach 3.0). Only with the advent of Mach 3.0, the first ``real'' microkernel, people started to notice that there is something wrong with Mach's original approach.
That said, it does not necessarily follow that microkernel-based system, or even Mach-based systems in particular, need to be slow. I do microkernel-related research myself, and my group has shown with L4Linux that a Unix single server can be implemented with very reasonable overhead on top of a ``real,'' second-generation microkernel - in this case, L4 (macrobenchmarks indicate that L4Linux has an overhead of about 2% to 3% when compared to the original monolithic Linux kernel).
I do not really know MacOS X's architecture well enough to give a well-informed statement, but my guess is that they have enough talent to avoid the most stupid mistakes.
The Darwin project is distinct from MacOSX.
I'm afraid this is completely incorrect. Darwin == MacOS X - Quartz and everything on top. For reference, I suggest you look at: Apple's Public Source website, Apple's MacOS X website, this block diagram and page, and Fred Sanchez's Advogato diary. The gist of all that is that MacOS X kernel developers and Darwin developers use the same CVS sources. The kernel is identical. Also, all of Darwin is included with MacOS X, as the underlying foundation.
Supreme Lord High Commander of the Interstellar Task Force for the Eradication of Stupidity
The real answer is just inertia from NeXT, but there are some true technical advantages to the mach base.
The mach interfaces for virtual memory and task communication have more scope than the standard unix ones. I was rather surprised when I found out that linux memory management is still basically based on sbrk (although you can fake up virtual memory objects with mapped files yourself).
There definately is some weirdness when you can have so many different types of threads: mach threads/tasks, unix tasks (threads also?), AppKit threads, and possibly some form of Carbon threads. They all come down to mach primitives, but they aren't interchangable.
John Carmack