Talk:macOS/Archive 13

This is an archive of past discussions about MacOS. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 10

Archive 11

Archive 12

OS X is not just UNIX based

Unending discussion on 'OS X is not UNIX based'

at the time of this writing, the introduction to the article falsely describes osx as "unix based." it is not, it's based on mach/darwin and nextstep. osx has a bsd emulation layer, which represents a partial and deviated unix system, as a module running on top of darwin. osx even uses a mach-specific binary format inside its bsd emulation, and a lot of apple's software interfaces with the mach kernel through mach-specific designs. also, apple's application code isn't unix based, it's based on objective C and object-oriented nextstep apis, not ansi C and posix/sysv/bsd/unix.

osx is bundled with a variety of gnu programs that are loosely based on unix designs, and those actually are ansi C/posix based, but osx isn't "based on" those components. you could probably remove every gpl'd console program and all of the gpl'd/lgpl'd libraries except for basic compiler/C libs, and finder and the rest of apple's objective C based software would still work.

the kernel isn't based on anything related to unix, their nextstep/cocoa apis can't even be accessed from ANSI C, and the vast majority of apple's own code is written in objective C which is incompatible with ansi C and unix designs.

so no, osx is not unix based.

a linux distribution with mono, ndis driver support, and wine would probably be more accurately called windows based than osx could be called unix based.

also, windows with microsoft's unix services package is comparably "unix based" in the sense of making some unix-like components and apis available on top of a non-unix OS.

I do understand the need to keep it simple, but the current claim is just not accurate, so if no details can be provided then it should simply be described as something like mach/darwin/nextstep based, because it is.

also, darwin never was free software, it's always been under a proprietary license, it's always been owned and controlled by apple, and apple decided a long time ago that intel users would not be able to recompile their own kernels and boot osx on them. http://www.macworld.co.uk/news/index.cfm?NewsID=14663&Page=1&pagePos=8

I won't restore any mention of the license and open/closed issue, but given that the unix claim is provably inaccurate, I think it's only reasonable to change it to something like "mach/nextstep based," to keep it simple, but correct.

70.55.42.238 (talk) 16:57, 5 April 2009 (UTC)

You should be aware that Mac OS X has been certified under the Single_UNIX_Specification, so it is in fact "Unix." Also, the Apple Public Source License under which Darwin is distributed has qualified as a Free Software license by the FSF. MFNickster (talk) 17:54, 5 April 2009 (UTC)

an operating system can provide a working, certifiable unix interface without being unix, or being based on unix. for example, microsoft's unix services could be certified if they were made fully compliant, or the cygwin system could be certified if it were made compliant, but that wouldn't make it accurate to say that windows is unix, or that windows is based on unix, even if those systems were included with windows by default. also, yes, a version of the osx kernel that can't be used with intel osx is distributed under an actual free software license, but the source is owned by apple, and they use it for non-free purposes that would be a violation of their own or any free software license if a third party were to use their source in that way. the intel osx kernel is not free software, it's not even open source. if darwin refers exclusively to the free software kernel then osx isn't using darwin, it's using a proprietary kernel that is also partially distributed as free software in the darwin project, which can't boot intel osx. 70.55.42.238 (talk) 19:32, 5 April 2009 (UTC)

I was under the impression that Apple did release the Intel kernel source. MFNickster (talk) 20:08, 5 April 2009 (UTC)

They did. There was just a delay between moving to Intel and the Intel kernel source being released. Most likely because they had more important things to do like get Leopard and the iPhone (which was still secret at this point) released. Of course, they didn't explain this at the time, so conspiracy nuts started coming up with all kinds of crazy stories. Let's not forget that Apple didn't have to open source Darwin in the first place, and they've derived very little to no benefit from it. Is there anything significant that has shipped as part of the Mac OS X kernel that came from outside Apple? AlistairMcMillan (talk) 01:31, 6 April 2009 (UTC)

everything I'm finding with google is saying that users are failing to compile and boot their own intel osx kernels. I can't find a single documented case of it working, in fact, but the failures are countless. I've even sought out apple chat channels and polled a lot of users, and I've still failed to find a single person who has even heard of a successful case of booting intel osx on a custom kernel. apple has clearly released most of the kernel, and they do claim to support using it to boot intel osx. mac users seem to widely believe that the osx kernel is completely open. I just can't seem to find any evidence that this is actually the case, and there's a lot of evidence that users are failing when they try to use it with osx, for a variety of reasons. but anyway, it's moot to me, as I have no objection to leaving the subject out of the introduction, so long as the osx kernel isn't explicitly represented as being open.

however, the mach kernel is not based on any unix or bsd concepts at all. it was forked into a project called "mach 4" by the university of utah to be used as a kernel in a unix OS, but apple based their kernel on mach 2.5, and as I said above, it is not a unix based kernel, and the operating system isn't based on unix or unix designs. in fact, according to apple's own documentation, the unix system in osx is a separate set of common tools that you can access from a terminal, and that is provided with a separate window system (x11) for unix gui programs. osx itself isn't based on this system, and everything related to unix could be removed from osx without affecting any of apple's software, which is based on objective C and object oriented nextstep apis that have nothing to do with unix and that can't even be accessed with straight C. osx is as based on unix as a windows machine with cygwin. that is, not at all.

so given that the stated reason for reverting to the "unix based" claim is incorrect (osx is based on mach 2.5 not the "mach 4" fork), I think it's reasonable to restore. 70.55.42.238 (talk) 02:52, 6 April 2009 (UTC)

Cygwin runs as a user process (application). XNU is about half BSD code, and has Unix system calls compiled into the kernel. That, to me, is enough to qualify it as a Unix kernel - albeit restructured to use Mach threads. MFNickster (talk) 04:18, 6 April 2009 (UTC)

Please read the Development section of our own article on Mach or read any other article anywhere about the history of Mach. It was developed from the BSD Unix sources as a replacement kernel for BSD Unix. The first running version of the Mach kernel ran within 4.2BSD, and later when the project released a full operating system, they basically released a version of BSD Unix with their kernel at the centre. How much more clearly does this have to be pointed out.

And the comparison with Cygwin is so ridiculous, so I'm not even going to bother touching that. AlistairMcMillan (talk) 06:01, 6 April 2009 (UTC)

the mach kernel was originally developed on top of a bsd system, but it isn't based on bsd or unixisms. a lot of kernels began in similar ways, rather than as independent executives, and it is accurate to say that its historical roots involved loading it into a bsd kernel. it isn't actually based on bsd designs, though. in fact, the fundamental concept is different and incompatible. it's a microkernel, based on C++, and original C++ programming interfaces.

you can't write a mach driver in C, it has to be C++, and you can't use anything resembling unix programming interfaces, they don't exist at kernel level in mach, at all. you have to use unique OO C++ systems that have nothing to do with unix, and that are incompatible with unix designs.

the same is true of apple's user software, it's based on OO objective-C apis (NSObject etc..) and not only do those apis have nothing to do with unix, you can't even access them with straight C or anything but objective-C syntax in an objective-C compiler.

so the kernel has nothing to do with unix. the user interface and all of apple's gui software have nothing to do with unix. they're not based on unix in any way, they're incompatible with it, unix programs can't interface with these systems unless they're converted into C++ or obj-C.

if apple had to remove everything related to unix or bsd from osx, that would mainly just involve deleting gpl'd software, and removing some bsdisms from their obj-c runtime. the kernel wouldn't need to be changed beyond simply deleting the bsd layer, and their various gui programs and libraries wouldn't need to be changed at all.

so no, osx isn't based on bsd or unix. the actual configuration of the current system is that from bottom to top, it's based on object oriented languages and apis that are unrelated to unix and that are incompatible with and inaccessible to unix designs. osx's unix components are a sideline, an optional set of secondary components that could easily be deleted, having only the effect of disabling "terminal" and a few third party daemons like apache.

so "based on unix" would seem to mean either: it has working unix support (like cygwin), or the history of the kernel involved developing it as a binary addon to a bsd kernel, which is historically accurate, but not the way it's done now. so the unix support that it provides is in no way the basis of the system, and the original implementation as a bsd addon is simply not consistent with current fact.

if its history as a bsd addon is to be mentioned, I think that if nothing else, it should be stated clearly, because "unix based" sounds, at least to me, like a present-tense assertion that the current system, rather than a previous version, operates based on some kind of unix scheme.

for instance, linux is a unix based system, it's a posix-based kernel, based on the normal model of a unix kernel, which is procedural ansi C monolithic kernel, it uses unix designs internally, it provides a unix-based programming interface to the system, it includes and fundamentally depends on a whole set of standard unix designs. there was even at least one lawsuit where a unix vendor claimed that linux illegally included their code. also, the bsd kernel that mach was installed into was a monolithic kernel, like linux, and much of its code could work in linux or vica-versa. 74.14.89.63 (talk) 15:04, 6 April 2009 (UTC)

Funny. One example why you are wrong: Remove the BSD layer from Mac OS X and suddenly you don't have any filesystems because you've just removed the virtual file system that they all depend on. Second example: Remove the BSD layer from Mac OS X and suddenly you can't connect to the internet because you just removed the TCP/IP stack. This is just my personal opinion but I believe that filesystems and TCP/IP are quite significant parts of Mac OS X that I'd miss. AlistairMcMillan (talk) 16:49, 6 April 2009 (UTC)

osx doesn't directly access those components, they're wrapped in an obj-C framework that has nothing to do with unix. it wouldn't be unix based if it was a bunch of windows software running on a version of wine that interfaced with mach specifics and a few bsd stacks, would it? btw winsock is based on bsd sockets, the windows api is loosely based on posix, and windows programs actually use those interfaces directly. 74.14.89.63 (talk) 17:11, 6 April 2009 (UTC)

Sorry but you couldn't be more wrong if you were trying. Yes there are Objective-C frameworks that applications can talk to, that sit on top of the BSD stuff. But the majority of the operating system isn't written in Objective-C. And all the Unix interfaces are available for developers to use whenever they want. Quake3 runs on Mac OS X and contains zero lines of Objective-C code. AlistairMcMillan (talk) 00:07, 7 April 2009 (UTC)

my assertion isn't that it doesn't provide a working unix subsystem. it does, just like wine is available for osx to run windows programs, just like a number of unix subsystems are available for windows. the point is that the kernel isn't a unix kernel, and apple's software isn't unix based. I could compile and run apple's code on windows without using a unix subsystem, what I'd need is a C++ system with mach's apis for the drivers, and an objective-C compiler and runtime for the gui components.

almost nothing in apple's code but some hidden internals of the obj-C runtime is based on the unix subsystem, and the unix subsystem is a module on top of the mach kernel, not the other way around.

you've barely addressed that point, or much of what I'm saying, and your "unix based" claim is just not consistent with the facts, or simple logic.

in short, the point of contention isn't whether it provides a unix subsystem, it's whether it's based on that system, and you haven't demonstrated why your claim is correct. 74.14.89.63 (talk) 02:11, 7 April 2009 (UTC)

The BSD portion of the kernel provides essential services to the rest of the system. Not just networking and filesystem support, as Alistair pointed out, but the security model, the printing services, the user management, and system configuration. It is not just a throw-away addition to the kernel, it really is the base of interaction with the system. About the only thing it leaves to Mach is the process model. MFNickster (talk) 03:03, 7 April 2009 (UTC)

I understand your point, and I think that is definitely worth documenting, but the current description makes it sound like osx has a unix kernel, and is written using unix designs, but that's not accurate, there's a lot more to the picture. if you took a windows machine, loaded cygwin on it, ran the obj-C runtime on that, and ran apple's gui software on that, would that be unix based? also, what is the criterion for "mach based" and/or "nextstep based?" under what circumstances would osx be mach based? if you had a unix kernel and a mach layer on top of it, would that be mach based rather than unix based? or what if you emulated a unix layer on top of a pure mach/obj-C system that had no bsd parts? would that be unix based or mach/nextstep based?

I mean, osx is based, in part, on some bsd components that it exports to apple's software through a non-unix and non-C interface, but as far as code written by people at apple goes, probably 95% of it is either in C++ or obj-C using non-unix interfaces, and that includes the kernel and almost all of the graphical interactive software. so to use language suggesting that it's a system that has a unix kernel and unix user software, unix bottom to top, is misleading and secretive, particularly when its certified unix support is clearly stated in the next sentence.

I mean, why not state clearly that the kernel is the mach kernel, not a unix kernel, and that the user software is based obj-C/nextstep apis, not procedural C/posix/bsd/sysv/svr4 apis, and then just add a mention where the article states that osx provides a certified unix environment, and add that its obj-C/nextstep runtime makes internal use of some of those features? 74.14.89.63 (talk) 13:04, 7 April 2009 (UTC)

I guess I don't understand why implementing Unix on top of Mach somehow makes it "not-Unix." MFNickster (talk) 15:34, 6 April 2009 (UTC)

well it definitely wouldn't be "unix based" without that, so the question is whether a unix layer on top of a non-unix system makes the system "unix based." if it does then almost every OS in existence, including windows, is unix based, because a C compiler and posix/bsd/sysv/svr4/etc.. have been ported almost everywhere, and the gnu unix tools that represent most of osx's unix support can run on any such environment. windows could be made certifiable. in fact, cygwin probably is certifiable, or close, but I doubt that anyone is going to spend hundreds of thousands of dollars to make it official. the standard windows api itself provides a portion of the necessary apis, from strcpy() to connect(). in fact, default vista and visual c++ probably provide 80% of the unix calls that the bsd module tacked onto mach does. 74.14.89.63 (talk) 17:11, 6 April 2009 (UTC)

Please stop wasting our time making nonsense arguments. AlistairMcMillan (talk) 00:07, 7 April 2009 (UTC)

if you don't have the time or expertise to resolve this, but you feel the current claim is correct (the reference doesn't support it, only that it has a unix interface and how to use it), find someone who can and will defend it, or if you also can't do that, leave my edit in place. osx's certified unix support is clearly stated in the next sentence, though also somewhat misleadingly, and you're deleting important information about what systems osx actually is based upon. mach and nextstep aren't the same as unix, and this is informative food for thought for the reader, to have its design as a mach/next system with unix support clearly indicated. it seems to me that the drive here is to sacrifice important and accurate information for the sake of more decisive association with a buzzword. 74.14.89.63 (talk) 02:37, 7 April 2009 (UTC)

Actually, Nextstep is typically included in the BSD branch of Unix family trees, because it derives from BSD 4.3 sources. It was considered a Unix variant. MFNickster (talk) 02:49, 7 April 2009 (UTC)

a nextstep runtime that makes internal use of some bsd services is a system involving a fork of bsd code, but software written on that framework isn't unix based. nextstep's obj-C programming interfaces are in no way based on unix designs. I've been forced to use them in order to do iphone development, and I'm also extremely familiar with unix programming interfaces. they don't resemble one another, they're not even compatible. for one, the obj-C apis are object oriented, and unix is not an object oriented system, so any OO framework is inherently not unix based or compatible with unix designs. also, nextstep's apis don't even resemble unix designs, the methods of doing things are completely different, the naming is in no way similar.

you could implement an obj-C runtime on a system having nothing to do with unix, and apple's graphical software could run on it. you could also do this by adding the required subsystems to mach, as mach drivers, and then switching the runtime over to those drivers. if you did that, osx could be unix free, and other than some internal reorganizing with the obj-C runtime, the entire system could go untouched.

literally, de-unixing osx would be limited to deleting the bsd module, implementing the features of a number of its stacks as mach modules, and modifying the internals of the obj-C system to work with the new modules. the rest of the kernel and all of the gui software wouldn't need to be changed because they aren't unix based at all.

also, if you did that, none of the existing kernel and gui code would even need to be recompiled. existing kernel modules would be unaffected because the kernel doesn't use the bsd module, and the existing gui code would be unaffected because it runs on top of the obj-C framework using unique obj-C apis. the obj-C runtime is the only component that would need to be modified and recompiled. 74.14.89.63 (talk) 13:42, 7 April 2009 (UTC)

This argument has nothing to do with improving the article; we use information drawn from reliable secondary sources, not from anonymous unix purists. Reliable secondary sources agree with OS X being "Unix-based". Let's drop this. Chris Cunningham (not at work) - talk 15:15, 7 April 2009 (UTC)

can you cite that? 74.14.89.63 (talk) 15:28, 7 April 2009 (UTC)

also, I'm not trying to bury the fact that osx has and makes use of unix components, what I'm saying is that it also has and makes primary and extensive use of non-unix components. 95% of apple's original code is non-unix, including the entire gui and kernel. doesn't that warrant coverage? what's the purpose of burying and concealing that information in favor of presenting it as simply being a unix system? 74.14.89.63 (talk) 15:31, 7 April 2009 (UTC)

Rule 1 of Wikipedia debate is that when someone starts accusing otherwise unengaged editors of "hiding", "burying" or "censoring" information it's because they're pushing their own personal point of view. The article does not currently avoid pointing out the various subsystems in Mac OS X; what it does not do is assign undue weight to convincing readers that there is a tangible difference between direct descendants of the code in the Lyons book and systems that everyone describes as Unix these days. This is as it should be. Chris Cunningham (not at work) - talk 15:38, 7 April 2009 (UTC)

I'm simply stating the fact that apple's code is almost entirely not unix based, and that the introduction misrepresents it as the opposite. this is provable, simple logic, demonstrated above. if the words burying and concealing offend you, or suggest motives you don't have, then I apologize. my point is only about the facts, and that the actual design of osx is not currently accurately represented.

in response to your point about the actual subject here, rather than the ad hominem excuse to dismiss what I'm saying, you seem to be missing the point entirely. again, I'm not trying to remove the fact that osx provides a certified unix environment, or that it makes use of those components. it does provide an environment that is a unix environment, and I'm not disputing that at all. particularly not on the grounds that it isn't a direct unix derivative, because its unix environment is, in fact, a bsd derivative.

my point is that there is more to osx than unix. a lot more. calling it a unix system is like calling windows with cygwin a unix system. it's like making a minor contribution to one component in an operating system and taking credit for the entire system. non-unix C++ and objective-C based apis represent the basis of almost everything that is unique to osx. the entire gui, the kernel core and the systems that all of its device drivers use. none of it is unix specific, unix based, or even compatible with unix designs.

osx has unix components. those are real, credible unix components based on bsd sources, and the objective C runtime makes use of those components. my objection is to describing it in a way that gives the inaccurate impression that anything beyond a tiny minority of apple's kernel and gui software that make osx what it is, is based on unix.

so yes, osx provides a unix environment, but it also provides and is based on other systems: modern object oriented designs in its vast majority. I'm saying give credit where credit is due, and keep it accurate. 74.14.89.63 (talk) 15:54, 7 April 2009 (UTC)

Look, there is really nothing particularly controversial here. Darwin is a certified Unix, and it serves as the base of the Mac OS X system, regardless of how different it may be from other Unixes (which, incidentally, can be very different from each other). You can compare it to Cygwin or Linux or any other non-certified Unix-like system all you want, but the fact remains that Darwin is certified and the others are not. It sounds to me like you are disputing that Darwin is Unix, and that the rest of the OS X system is based on it. Both points are already cited and verified, so it looks to me like the case is closed. MFNickster (talk) 17:37, 7 April 2009 (UTC)

again, I'm not saying that osx doesn't provide a working, certified unix environment, or that the claim should be removed. the only question is whether it's based on that environment, or whether it provides a certified unix environment but is primarily based on non-unix C++ and objective-C systems. the existing reference for the based on part only supports that it provides a unix system, not that it's based on that system. though, I don't even deny that a number of important bsd components are used by the obj-C runtime. my point is that the kernel and gui are written in C++ and obj-C and are not unix code or even compatible with unix designs. keep in mind that C++ and objective-C didn't even exist when unix was developed, so that goes to show you that the >95% of apple's code that is written in those languages is not unix code, in the sense of being derived from unix, or in line with the standards and capabilities that made up unix. 74.14.89.63 (talk) 17:59, 7 April 2009 (UTC)

You seem so concerned with what Unix was that you don't see what it is now. Besides, the Mach and BSD portions of the kernel are in C[1], not C++ or Objective-C. The GUI has nothing to do with what is and isn't Unix. All application execution environments in Mac OS X, from Carbon to Cocoa to Java, rely on the BSD interfaces. All applications in Mac OS X are Unix processes. MFNickster (talk) 18:21, 7 April 2009 (UTC)

the unix specification is based on ANSI C, it's a set of procedural C apis and headers, an interactive shell, and a number of programs, based on what unix systems did in the 70s. osx does use a number of bsd and gnu sources to meet that specification, and its objective-C runtime does use the bsd system internally to provide objective-C programming interfaces. the document you pasted is simply wrong about C++, by the way.

here's the source for darwin: http://www.opensource.apple.com/darwinsource/10.5.6/

you can pick a module at random and view the source, it's all C++ 74.14.89.63 (talk) 20:25, 7 April 2009 (UTC)

Download the "xnu-1228.9.59" package and look in the "bsd" and "osfmk" directories (which is where the sources for the BSD and Mach parts of the kernel are). There is no C++ in there. MFNickster (talk) 00:19, 8 April 2009 (UTC)

exactly my point. mach (not xnu) is an object oriented C++ system, not derived from or compatible with the unix specification or a unix system, not even accessible through straight ANSI C, not using or providing any part of the unix specification. though, it was developed as a discreet module running on top of bsd. on the other hand, the bsd module that runs on top of mach in xnu is derived from an authentic procedural C based unix system, and I never meant to suggest otherwise. it essentially is bsd, adapted to be a guest process on mach. also, just as you could run the obj-C runtime on cygwin, you could adapt bsd to be a guest on windows to provide some unix services, to make apple's obj-C runtime work. not that I mean to promote windows, the only point, as always, is that this very real, certified unix layer on osx is not the basis of the OS, even though it does provide some services that the obj-C runtime uses behind the scenes to provide obj-C apis that have nothing to do with unix. 95% of apple's original code is either C++ in mach, or obj-C in the runtime, having nothing in the source code to do with unix, and nothing in practice to do with unix beyond having some bsd subsystems driving the particular obj-C runtime that apple uses. 70.30.13.90 (talk) 01:33, 8 April 2009 (UTC)

Did you even look at the code? Mach has no C++ in it. XNU is not Mach, it is a hybrid kernel with Mach and BSD integrated, and takes the place of a BSD-style Unix kernel. XNU is a Unix kernel, how can you not see this? MFNickster (talk) 03:50, 8 April 2009 (UTC)

again, xnu = mach (C++) + bsd (unix C)

the mach kernel is non-unix (all of apple's kernel code, part of the obj-C runtime, and none of the gui software are designed around this)

the bsd module is unix (none of apple's kernel code, part of the obj-C runtime, and none of the gui software are designed around this)

the obj-C runtime provides the obj-C language and nextstep/cocoa apis which have nothing to do with mach or unix interfaces (the gui software is designed based on this)

the bsd system wraps over mach to provide its environment, and the obj-C/nextstep/cocoa runtime wraps over the bsd and mach systems to provide its environment

mach is at the core, bsd uses and augments that, and the obj-C runtime provides extensive services that completely wrap over both

so if we say that "based on" refers to the base component in the internal configuration of the system then it's based on mach

or, if we say that "based on" refers to the specs and standards used to write source code then apple's gui software is based on nextstep-specific obj-C interfaces that have nothing to do with unix

in any case, calling it "unix based" is just not accurate, unless it could be "mach based" and "unix based" and "nextstep based," because it's really based in different ways on a number of completely separate systems, and "unix based" in a mutually exclusive sense isn't accurate by any definition 70.30.13.90 (talk) 04:51, 8 April 2009 (UTC)

about apple's gui software, the question is whether it's based on unix. does it use the features of the unix specification? is it written in C? does it use the headers and apis of the unix specification or some variant? does it use the interactive shell and associated programs from the unix specification? the answer is a definitive no. osx's graphical components are written in objective C, they use object oriented nextstep apis and cocoa, and those can only be accessed from objective-C. they're only "based on" unix in the sense that the particular objective-C runtime they use in the current build of osx uses some bsd components. they could just as easily run on a runtime with different internals, though. apple wouldn't have to modify their gui software if they suddenly had to remove anything related to unix. they would only have to modify the objective-C runtime.

also, are you saying that a java-based operating system would be "unix based" if the vm used a bsd kernel internally? and if that's your standard, then isn't osx mach based? 74.14.89.63 (talk) 20:25, 7 April 2009 (UTC)

Can I just point out one last thing. Mac OS X doesn't actually run the Mach kernel. The kernel in Mac OS X is XNU, which is a combination of Mach, BSD code and some other stuff. Pull out the BSD code and you don't even have a kernel anymore.

Also comparing the Unix parts of Mac OS X to Cygwin running on Windows is ridiculous. Take the Cygwin files out of a Windows system and you still have a working system, take the Unix files out of Mac OS X and you have a completely dead system. AlistairMcMillan (talk) 17:35, 7 April 2009 (UTC)

Indeed - XNU is a Unix kernel. It does what a Unix kernel does, despite it's modular design being different from previous Unix kernels. It may not be 100% compatible with other BSD-type kernels, but that has been true ever since BSD first forked into different variants. MFNickster (talk) 17:47, 7 April 2009 (UTC)

xnu is mach with a bsd module. the microkernel and its drivers aren't based on anything unix related, they're not a bsd fork, they're not bsd compatible, they provide nothing related to bsd or unix. the bsd subsystem only serves its own environment. it utilizes mach drivers but doesn't provide anything in the kernel system.

an analogous configuration would be windows + cygwin + apple's obj-C runtime + apple's gui software. other than missing non-unix mach specifics, it would be very easy to set that up, the obj-C runtime would require almost no modification to use cygwin instead of bsd, and the osx gui software probably wouldn't even need to be recompiled. also, in that setup, if you removed cygwin, you'd break the obj-C runtime and therefore the gui, just like removing bsd from osx.

also, mach could be extended with the systems that the bsd layer provides, and the obj-C runtime could be adapted to use that. the microkernel, its drivers, and the gui software wouldn't need to be changed. 74.14.89.63 (talk) 17:59, 7 April 2009 (UTC)

Nonsense. Open Activity Monitor, select WindowServer, hit Inspect, select the Statistics tab, cast your gaze down to the bottom right-hand corner of the window. The bit where it says "Mach System Calls" and "Unix System Calls". On my system it is currently sitting at "Mach System Calls" ~68000000 and "Unix System Calls" ~57000000. Everything depends on the BSD side of the kernel.

And let me point out again. Mach came from BSD, was developed for BSD, was distributed as part of BSD operating systems, so unless you are going to start arguing that BSD is not Unix, then please find something better to do with your time. AlistairMcMillan (talk) 19:37, 7 April 2009 (UTC)

yes, the objective C runtime uses the bsd system internally, that's what I said, that's why apple's gui software generates bsd calls. of course, the bsd system runs on top of mach, so the gui software is either objective C based (all the gui stuff is written in obj-C, not anything related to unix), or it's mach based if you go by the lowest layer, but the bsd software used by the runtime is on top of something, and below something. it could be replaced without modifying the kernel or the gui software, only the obj-C runtime which is a tiny portion of osx.

mach didn't come from bsd, it was developed as a module in a bsd system. you can have mach without bsd. in fact, mach isn't inherently related to bsd at all, beyond the footnote of how it was originally hosted. it's xnu that has bsd components in it. 74.14.89.63 (talk) 20:25, 7 April 2009 (UTC)

here's a diagram that illustrates how osx is layered: http://jl.mu/c/osxlayers.jpg 70.49.147.185 (talk) 17:25, 8 April 2009 (UTC)

Did you make that diagram yourself? MFNickster (talk) 18:55, 8 April 2009 (UTC)

yes 70.49.147.185 (talk) 19:00, 8 April 2009 (UTC)

Interesting. Here are a couple from Apple's Kernel Programming Guide : [2][3] MFNickster (talk) 21:27, 8 April 2009 (UTC)

their diagrams seem to conflict with each other, with one showing bsd as a completely separate system, and the other showing it as a part of the layer below apple's framework. the latter is currently accurate, but it makes me wonder if they're planning to implement the missing systems in mach to make their framework entirely mach based. that would give them a working system where they own every line of code, rather than just having the right to use bsd code to provide some essential services for the framework. I'm just speculating, but apple have published at least one variant of the diagram that depicts a bsd-free hierarchy, so the depiction wouldn't seem to be an isolated misunderstanding. 70.49.147.185 (talk) 00:46, 9 April 2009 (UTC)

No, they do not conflict - one diagram illustrates the structure of the kernel, including BSD code, and the other includes the BSD APIs as an application environment. Likewise the variant you linked to is not "BSD-free," the bottom box represents the kernel environment including BSD code. Also, Apple does not own Mach; it was licensed by Carnegie-Mellon under a BSD-style license. MFNickster (talk) 02:16, 9 April 2009 (UTC)

having a box that says "kernel environment" on which apple's software is based, and then a separate box that says "bsd" certainly seems to me to give the impression of bsd being separate from the kernel and apple's core services.

that's true that apple would have to rewrite the mach microkernel, but that would be a tiny project compared to rewriting the bsd components.

they may never do that, though. I really have no idea. certainly, apple's own publications do support what I've been saying, that mach isn't a unix based system, that apple's mach code is C++ based, and that the bsd module that runs on mach in xnu is the target of only a portion of the internal implementation of apple's core services, which is the platform that their gui software targets.

also, the dependence of apple's runtime on bsd is really only a matter of reverse engineering and conjecture.

we know that mach isn't based on the bsd module in any way, but rather, the bsd module runs on top of mach.

we know that apple's runtime, on which its gui software is based, doesn't expose anything related to unix.

so as far as being "unix based" goes, it's really only a matter of pseudo-documented dependence of the core services on the bsd system. afaik, the runtime is closed source, though, so it's hard to confirm anything about its internals.

though, I acknowledge that the runtime clearly does make internal use of a variety of bsd features.

also, if you ask apple how to write a driver, they tell you to target mach, using mach and apple specific C++ based apis. I doubt that you even can implement a driver on top of the bsd system.

if you ask apple how to write a program, they tell you to target cocoa with nextstep and apple specific objective-C based apis. no part of unix is included in that.

apple doesn't write their software above some of the internals of their core services based on bsd, and they don't suggest that third parties write anything bsd-aware.

in fact, xcode doesn't even have a template for a bsd/unix program. it has a C++ template, a mach kext template, a number of java templates, and a whole variety of templates for objective-C based programming interfaces that are unrelated to unix. 70.49.147.185 (talk) 02:53, 9 April 2009 (UTC)

If you ask Apple how to write a driver, they tell you to target I/O Kit, which is part of the kernel environment (written in C++), not Mach (written in C). I recommend you do as Alistair suggested above and open Activity Monitor, and see just how many "Unix system calls" are in use by the Finder and WindowServer - that is a measure of how much Apple's software relies on BSD.

Also, I don't know what version of XCode you're using, but my v2.5 install has a "BSD" folder in "Target Templates." The BSD/Unix templates are the Command Line Utility templates. There are also clearly-marked templates for BSD dynamic and static libraries. MFNickster (talk) 03:10, 9 April 2009 (UTC)

well either way, the kernel and driver systems aren't based on or related to any part of bsd or the unix specification, so that's moot and resolved.

No, it is not resolved, because you still don't seem to understand what you're looking at. I'm going to recommend you read the entire Kernel Programming Guide before continuing discussion, because that documentation makes it clear that Apple/NeXT took the FreeBSD kernel and restructured it to run on Mach as CMU had done with 4.3BSD, replacing the driver interfaces with I/O Kit. It's still a BSD kernel on a functional level. MFNickster (talk) 03:54, 9 April 2009 (UTC)

can you point to some aspect of the unix specification in mach, apple's kexts, or any part of the osx kernel but the bsd layer? 70.49.147.185 (talk) 04:32, 9 April 2009 (UTC)

as for xcode, this may be a telling example. I'm using 3.1.2, I don't have a bsd folder. I do have a single bsd library project in each of the "Dynamic Library" and "Static Library" folders, and nothing bsd or unix related in my "Command Line Utility" folder or anywhere else. ironically, I have non-unix CoreFoundation/CoreServices templates in the "Command Line Utility" folder. so there seems to be a pattern here, and it isn't basing things on unix.

I checked 3.1.2 on another machine, it also has a "BSD" folder in /Developer/Library/Xcode/Target Templates. MFNickster (talk) 03:54, 9 April 2009 (UTC)

that's true, it exists, it has 4 entries: dynamic library and static library (which I mentioned), shell tool, and object file. this means absolutely nothing and is completely moot, though. there's an incredible wealth of evidence to the effect that apple uses and promotes objective-C and cocoa, including countless explicit statements from the company, and any claim to the contrary goes way beyond the scope of trying to prove that osx is "unix based." even within those xcode templates, the 4 bsd samples are minor and represent a tiny minority of the templates. 70.49.147.185 (talk) 04:32, 9 April 2009 (UTC)

also, the fact remains that apple uses cocoa and objective-C, and promotes cocoa and objective-C to developers.

Moot point, because they also provide BSD interfaces and tools for those who want to use them. MFNickster (talk) 03:54, 9 April 2009 (UTC)

but apple doesn't use them, they use cocoa, and they tell you to use cocoa. the question is what apple is basing the platform on, not what they support. also, as always, how is unix support even supposed to imply unix basing? why does any hint of unix trump extensive use and integration with non-unix systems? 70.49.147.185 (talk) 04:32, 9 April 2009 (UTC)

the finder and window server actually pre-date cocoa (finder uses carbon), so that difference from more modern components, too, is telling. if you look at apple's samples and documentation, and most of their gui software, they don't use or suggest unix apis at all at this point. though, you'll still see bsd calls for straight obj-C/cocoa, because the runtime uses the bsd system for a number of things.

so yes, I do agree that their runtime uses mach and bsd internally for a variety of important services, but it uses them to provide non-unix programming interfaces, which is a critical distinction.

also, keep in mind that everytjomg the bsd layer does inevitably goes through mach and/or a C++ kext.

are you really claiming that limited internal use of bsd features by the runtime/core services makes osx somehow more "unix based" than it is based on any of the systems that apple actually writes their kernel and program code around, documents, and promotes to developers? 70.49.147.185 (talk) 03:37, 9 April 2009 (UTC)

No. For the last time, I'm saying that Darwin is the base system of Mac OS X. Darwin is a BSD variant, and a certified Unix. It is derived from Unix, provides essential system services, and allows Unix development alongside Apple's proprietary application environments. All the documentation reinforces the history and architecture of the system as being Unix-based. So please stop wasting our time with this. MFNickster (talk) 03:54, 9 April 2009 (UTC)

well why is the bsd module what osx is "based on?" why isn't it based on mach? why isn't it based on cocoa? why isn't it based on objective-C? why isn't it based on nextstep (as is NSObject etc..)?

if it used a mach module on a bsd kernel as the back end for the runtime, would that make it mach based?

if bsd features are replaced with kexts and the runtime is switched onto those, at what point is it no longer "unix based?"

would it still be "unix based" if it didn't use anything related to unix at all?

maybe we need to define what "based on" means, because the claim seems to boil down to some loosely defined combination of mach having began as a bsd kernel module, and bsd now being used as a module in mach to provide some of the internal backing for the core services.

I have a feeling that you wouldn't be insisting that osx was "windows based" if it used wine on top of a bsd kernel for some internal purposes, and/or if the kernel had started as a windows driver. 70.49.147.185 (talk) 04:22, 9 April 2009 (UTC)

Oh man... are we done yet? I know wikipedia is not a democracy, but it is indeed a "factocracy". The side claiming OS X to be unix-based have plenty of sources, including Mac OS X Leopard on intel being _certified_ UNIX 03. On the other hand, there virtually is no source supporting the other side. I think the discussion should be over. This section is 45 KB long for goodness' sake. Dravick (talk) 03:57, 9 April 2009 (UTC)

I think I'm about done. :) MFNickster (talk) 04:09, 9 April 2009 (UTC)

osx providing a certified unix system isn't in debate here, I have no objection to that claim. however, providing a unix environment, even a certified one, isn't the same as basing your system on unix. see above. or, a simple example:

unix: fprintf(stderr, "this works on machines that comply with the unix specification. apple doesn't base their software on this programming interface, and they don't recommend it to third parties.\n");

nextstep: NSLog(@"this is not supported by the unix specification or ANSI C. apple bases their software on this programming interface and recommends it to third parties. only osx supports this programming interface, and only within its objective-C runtime. it won't work in a unix program on osx, it won't work under any circumstances on other unix systems." ); 70.49.147.185 (talk) 04:22, 9 April 2009 (UTC)

Oh, for Pete's sake... you can develop with GNUStep on Linux, but if you write a program to that API, it's not a "Linux" program?? MFNickster (talk) 04:30, 9 April 2009 (UTC)

nextstep code isn't linux based, even though some of it (not much of cocoa) can run there. a lot of software is based on the unix specification, or generalized unix-like semantics. a program that will compile and work on all certified unix machines is unix based. that is, a program based on ANSI C and unix apis is unix based. a C# program isn't unix based, it's C#/CLI based, able to run on C# environments, not directly supported by unix. programs written in languages (and associated apis) like C#, java, php, perl, ruby, python, etc.. are operating system (but not runtime) neutral, not based on unix or windows or another OS specification. that's a big part of what makes java what it is.

in fact, all software essentially just conforms to one set of standards and/or semantics, or another. that's all that software is, instructions and data conforming to a particular standard. unix based software conforms to the unix specification, or something semantically similar.

I wouldn't want someone to call my OS a linux distribution if I wrote an original OS in C# and used a linux guest with mono for a runtime on top of a custom kernel. I'd feel that people were being deceived and that I was being denied due credit. 70.49.147.185 (talk) 05:01, 9 April 2009 (UTC)

Yep, we're done. There's no support for changing the article, so this is mostly just one user arguing Unix purity for the sake of it. I'm going to chuck this straight into archives once it's died down. Chris Cunningham (not at work) - talk 08:26, 9 April 2009 (UTC)

this false assertion that I'm denying that osx contains a working, certified unix environment, and that I'm doing so in defense of unix, seems to keep coming up.

I'm fine with stating that osx provides a certified unix environment, because it does.

my objection here is to the bizarre assumption that providing a unix subsystem, among other, more important and extensive subsystems, somehow trumps all other subsystems and makes the system "unix based."

going by wikipedia's entries on formal logic, the support for the "unix based" claim has been fallacious in a number of ways:

false cause:

argument: mach began as a bsd addon, bsd is a type of unix, mach is therefore unix based.

problem: mach doesn't implement or consume unix designs, it isn't unix conformant. so if a platform contains nothing related to unix, can it be forever "unix based" if it was developed on top of a unix system in its early stages? if you rewrote mach as a windows driver and substituted that version in osx, would osx become "windows based?"

also,

argument: osx provides and makes some internal use of a unix subsystem, therefore osx is unix based.

problem: "based" has not been defined in a way that would support the claim, and osx provides and extensively utilizes a number of environments that are unrelated to unix.

irrelevant conclusion:

me: having been developed on top of bsd doesn't make it bsd.

response: you're wrong, it was developed on top of bsd.

also,

me: providing and even making some internal use of a certified unix environment doesn't make a system unix based.

response: you're wrong, osx does provides a certified unix environment, this has been proven. this issue is now dead, your edits will be reverted if you change the article.

fallacy of composition:

argument: some of the subsystems in osx are based on unix in one way or another, therefore the system as a whole is unix based.

problem: a number of components being "unix based" doesn't make osx "unix based." osx is based on a variety of more important, more extensive, more exposed, more central systems. bsd is in no way the central, mutually exclusive basis of osx, even though it was originally used to host mach, and it's currently hosting part of the core services. 70.49.147.185 (talk) 15:36, 9 April 2009 (UTC)

Apple doesn't recommend fprintf to third parties? http://www.google.co.uk/search?q=site%3Adeveloper.apple.com%2Fsamplecode%2F+fprintf Just a little bit of research would really help make your comments more credible. AlistairMcMillan (talk) 08:49, 9 April 2009 (UTC)

see apple's document Mac OS X Technology Overview: Application Technologies

the bsd system is a footnote, representing about 2% of the document, and, quoting them directly, they only recommend it for:

UNIX developers familiar with the FreeBSD and POSIX interfaces

Developers who want to create text-based scripts and tools, rather than tools that have a graphical user interface

Developers who want to provide fundamental system services through the use of daemons or other root processes 70.49.147.185 (talk) 15:36, 9 April 2009 (UTC)

no objections to what I'm saying have been raised in several days, and the point hasn't been directly addressed that certified unix support in osx has been referenced and proven, but osx hasn't been demonstrated as being unix based. the article currently states that osx is "a Unix-based operating system" and that it "is certified UNIX 03." I say the former is simply inaccurate, and the latter states unix certification in a way that also suggests basis. to summarize:

the current reference for the "unix-based" claim doesn't support being based on unix in any way, it only supports the fact that osx provides a working, certified unix environment. so if nothing else, it currently isn't referenced. the arguments in favor of the "unix-based" claim seem to be that mach was originally tested as a guest on bsd, that osx runs a kernel-level bsd module on mach, that the core services make internal use of the bsd module, that osx makes a certified unix environment available, and that one or more of these factors make osx "unix-based." I don't dispute any of those facts, but I say that it doesn't make osx unix based because of the fact that the bsd layer represents a small portion of the set of systems that apple uses and recommends using to develop drivers and applications for osx,[4][5] that not only is the bsd module's role in those systems almost entirely internal but that it also represents only a portion of kernel-based services,[6] and that the mach kernel, rather than bsd module is the core kernel component of the system.[7] also, the fact that the mach kernel began as a guest on bsd is moot, unless the argument is that mach and any mach-based systems are forever "unix based" for historical reasons, whether they actually contain anything related to unix or not. also, the mach kernel doesn't contain or use unix designs, and apple's kernel code is based on non-unix style guidelines and C++ where unix is based on C. [8][9]

so given the above facts of what use and integration with bsd/unix osx has and doesn't have, it would seem to be a question of what based means in this context, and it seems to be a vague generalization. if based means the core kernel then osx is mach based. if based means the driver and application technologies that are used and recommended for use by apple, then osx is based almost entirely on non-unix designs. if based means what internally drives the top-level services then it's a combination of mach, bsd, and then a variety of next- and osx-specific core services that completely wrap over mach and bsd. and if based is simply the historical hosting platform of the kernel project, I would argue that is not relevant or informative in this context, whether the host was unix-based or not.

so in order to reflect that osx provides a certified unix environment, but that it is based on a variety of systems of which bsd is only a part, I propose changing:

Mac OS X, whose "X" represents the Roman numeral for "10" and is a prominent part of its brand identity, is a Unix-based operating system,^[1] built on technologies developed at NeXT between the second half of the 1980s and Apple's purchase of the company in early 1996. Its sixth and most recent version, Mac OS X v10.5 is certified UNIX 03 while running on Intel processors.

to:

Mac OS X, whose "X" represents the Roman numeral for "10" and is a prominent part of its brand identity, is built on Darwin, Java, and a variety of technologies developed by Apple.^[2] Its sixth and most recent version, Mac OS X v10.5 provides a certified UNIX 03 environment while running on Intel processors.

I've removed the mentions of being based on unix and built on next because darwin explicitly covers both, and I didn't mention mach for the same reason. I think this is clearer, more accurate, more concise, and it's neutral on citing one technology or the other as the mutually exclusive basis of osx. I also clarified the "is certified unix" claim to be more neutral and accurate, but osx's certified unix support is still mentioned.

if there are any specific objections to these changes, please state them, or if none are stated then I plan to either sign up for an account or seek the assistance of an administrator in order to implement them.

70.50.178.185 (talk) 16:14, 12 April 2009 (UTC)

Here are my final objections. Whether "based on" means "inspired by," "derived from," or "uses as a foundation," all three are true of the current Mac OS X. The description of the OS as being Unix or "Unix-based" is well-documented, by Apple and third parties. MFNickster (talk) 17:54, 12 April 2009 (UTC)

"Max OS X version 10.4 Tiger combines a robust and open Unix-based foundation with the richness and usability of the Mac interface"[10]
"Mac OS X is now a fully certified UNIX operating system"[11]
"Mac OS X is UNIX-based, open source and based on open standards"[12]
"Many developers who are new to Mac OS X are also new to BSD, an essential part of the operating system’s kernel environment. BSD (for Berkeley Software Distribution) is based on UNIX."[13]
"Darwin is not Mac OS X. It can be thought of as a subset of Mac OS X - essentially the low-level foundation upon which Mac OS X is built."[14]
"...the Cupertino, Calif., Mac maker has been working steadily on maintaining current, PC-compatible builds of its Unix-based OS."[15]
"The Mac OS X is based on Unix" [16]
"Apple has always touted OS X as UNIX-based"

"Mac OS X 10.5 on the Intel platform is a "true" UNIX OS, rather than just being UNIX-like."[17]

"Unix-Based Mac OS"[18]
"It is the first desktop, Unix-based operating system to reach the mass market."[19]
"Users are introduced to the UNIX-based foundations of Mac OS X"[20]
"Unix-based Mac OS X is very much more powerful and complex than the old Mac OS"[21]
"Mac OS X is the operating system for Apple's Macinosh computers and it is based on the Unix-based OPENSTEP operating system developed by NeXT Software"[22]
"The most widely-sold UNIX-based operating system, Mac OS X"[23]

the driver system and gui software are not actually based on unix, but the inaccurate assertion that providing unix is indistinguishable from unix basing does seem to be extremely common, including in some of apple's more generalized documents, which does provide the appearance of compelling support for what you're saying. I stand by the assertion that, in its vast majority, osx isn't actually based on the unix environment that it provides. I contend that I've proven that above and that the meat of apple's own documents confirms it, but when apple themselves have a number of other documents that misrepresent the system, and a vast number of users seem to feel it's important to draw no distinction between providing a unix environment and actually writing your software based on that environment, rather than, say, java or cocoa, I'll probably face a continuing series of reverts and bans if I try to make the article accurate or even just neutral on the subject.

so, the lie stands: osx isn't based on mach, nextstep, objective-C core services, cocoa, quartz, quicktime, and java, as apple's more detailed documents explicitly say. it's "unix based," and as far as the introduction to this article goes, the indication will be that apple's drivers and gui software are based on the definitions of the unix specification and could compile and work on other unix-conformant platforms. that's what we'll tell users because that's the public image that everyone wants. oh well, you win, I give up. 70.50.178.185 (talk) 18:34, 12 April 2009 (UTC)

Your arguments may have validity, but Wikipedia is not the place to make them. Per WP:NOR: "Wikipedia does not publish original research or original thought. This includes unpublished facts, arguments, speculation, and ideas; and any unpublished analysis or synthesis of published material that serves to advance a position. This means that Wikipedia is not the place to publish your own opinions, experiences, or arguments."

"...Research that consists of collecting and organizing material from existing sources within the provisions of this and other content policies is encouraged: this is "source-based research", and it is fundamental to writing an encyclopedia. Take care, however, not to go beyond what is expressed in the sources or to use them in ways inconsistent with the intent of the source, such as using material out of context. In short, stick to the sources."

So, again, unless you have some sources to back up your assertions, policy demands that the article should remain as is. MFNickster (talk) 18:42, 12 April 2009 (UTC)

the assertion that osx's drivers are based on C++ and non-unix designs, and that its applications are based on cocoa and other non-unix systems is referenced. [24][25][26]

but it does conflict with a common lack of distinction between osx providing a unix environment and osx being unix based, which, as you pointed out, is even supported by some of apple's other documents.

I'm saying that the common perception isn't accurate, but it is so common, so motivated, so widely supported, even by some sources within apple, that I can accept that accuracy isn't going to win out, here. 70.50.178.185 (talk) 19:14, 12 April 2009 (UTC)

Your sources support the fact that Darwin uses I/O Kit in place of traditional Unix driver models. Do you have any sources indicating that any Unix standard requires a particular driver model? AFAIK, only the interfaces are specified, and Darwin meets the requirements. MFNickster (talk) 19:48, 12 April 2009 (UTC)

the burden of proof is on supporters of the "unix-based" claim to demonstrate that meeting the unix specification requires that the system be based on unix. though, I have demonstrated that it does not, and that there is no conflict between exposing a unix environment, and basing a system's drivers and applications on other models. osx and windows are two examples of platforms that can host unix, but that aren't based on unix. 70.50.178.185 (talk) 20:42, 12 April 2009 (UTC)

You have it backwards. The sources have always described Mac OS X and Darwin as "Unix-based." One objection people raised to this is that it did not meet the Unix spec, and was not a certified Unix. That objection has been removed, so the burden of proof is on you to provide support for your claim. MFNickster (talk) 21:11, 12 April 2009 (UTC)

I agree with MFNickster, every source ever presented in this argument supported that Mac OS X is UNIX-based. I think the major discussion here is more, what does it mean to be UNIX-based. And to that question, everyone answers the same thing except you. Dravick (talk) 21:14, 12 April 2009 (UTC)

does meeting the unix spec imply that a system is unix based? is windows unix based if you install cygwin? what if cygwin was certified? the fact that osx's unix support is certified is moot to the "unix-based" claim, unless you can prove that unix certification requires unix basing, which hasn't been referenced.

the only legitimate evidence for the claim seems to be that a variety of sources have mistakenly confused unix support with unix basing, including at least one source at apple. apple does have many documents that explicitly state that osx drivers and applications are actually based on non-unix languages and interfaces,[27][28][29] and that the system is primarily not internally based on unix,[30][31] but the confusion between hosting unix and being unix seems to be common enough that there are some fairly credible references to contradict apple's explicit documentation of how osx works. 70.50.178.185 (talk) 22:25, 12 April 2009 (UTC)

For the last time, Darwin is Unix. It is based on Mach, BSD and I/O Kit. Mac OS X is based on Darwin, in that all the application environments rely on Unix processes, Unix networking, and Unix filesystem interfaces provided by the kernel. The docs support this; case closed. MFNickster (talk) 22:29, 12 April 2009 (UTC)

if it didn't expose the bsd system at all, would you still say it was unix based?

Yep. But it does. MFNickster (talk) 02:47, 13 April 2009 (UTC)

but in that case, exposing a unix environment isn't your criterion, so the fact that osx exposes one is moot. that also explains why you feel that cygwin-based configurations don't shed light on this subject. 70.50.178.185 (talk) 15:37, 13 April 2009 (UTC)

if the user software was all windows software running on wine, would you call osx unix based?

Yep. Linux running Wine is still Linux, after all. Why should Darwin be any different? MFNickster (talk) 02:47, 13 April 2009 (UTC)

so it seems to be a matter of the lowest layer of the system rather than the design of application software, the directly supporting frameworks, or any intermediary or secondary layers. also, I notice you didn't say that it depends on whether wine is completely consistent with windows specs, so the issue of conformance seems to be moot. 70.50.178.185 (talk) 15:37, 13 April 2009 (UTC)

also, what about the fact that the bsd layer represents only a portion of the internal backing for the core services?

Irrelevant. Every Unix has software that runs on libraries which are not part of the core OS. MFNickster (talk) 02:47, 13 April 2009 (UTC)

that seems like a reasonable argument, so long as you apply it consistently. 70.50.178.185 (talk) 15:37, 13 April 2009 (UTC)

what makes the bsd layer the mutually exclusive base?

The fact that it is a complete, certified Unix OS even without the services and applications on top. MFNickster (talk) 02:47, 13 April 2009 (UTC)

I thought you said that exposing a unix system isn't the criterion. also, are you saying that windows with cygwin is unix based? also, by that standard, wouldn't wine on osx somehow become the basis of the system if wine were completely windows-conformant? 70.50.178.185 (talk) 15:37, 13 April 2009 (UTC)

did you know that the bsd layer has no drivers of its own, and the bsd layer itself is adapted to be based entirely on services provided by mach and apple's drivers? 70.50.178.185 (talk) 22:46, 12 April 2009 (UTC)

Irrelevant. The fact that they changed the driver structure doesn't affect the core Unix interfaces the system depends on.

but in this scenario, bsd is a compatibility layer, a guest, a runtime, based on a supporting lower level set of drivers and apis that have nothing to do with unix. whether it's unix-conformant or not, why is it more the basis of the system than the next layer down, or the next layer up? by your own reasoning, isn't the one true basis of osx mach/iokit, not bsd? 70.50.178.185 (talk) 15:37, 13 April 2009 (UTC)

Again, it doesn't matter what arguments you or I make - the article has to be referenced from notable sources on the topic. MFNickster (talk) 02:47, 13 April 2009 (UTC)

70.50.178.185, nobody's going to buy a "OMG THE WHOLE WORLD IS WRONG EXCEPT FOR ME!" argument from someone who prefers to remain completely anonymous. So, please, man up with some proof and reliable sources, or take your grump and bugger the hell off. Warren -talk- 21:55, 12 April 2009 (UTC)

Warren, I know it feels like arguing in circles, but please remember to be civil. MFNickster (talk) 22:08, 12 April 2009 (UTC)

Don't you lecture me. The reality is that people who come to Wikipedia and try and prove what they're saying by providing links to sources which state precisely the opposite of what they're arguing, as this anonymous person has just done, are wasting our collective time and are thus being disruptive and damaging the encyclopedia. They need to take their malfunctioning brains and bugger the hell off. We're here to build an encyclopedia, not to have an argument. Warren -talk- 22:34, 12 April 2009 (UTC)

No matter how much you disagree with him, telling him to "bugger the hell off" is not civil behavior. MFNickster (talk) 22:39, 12 April 2009 (UTC)

Which part of "don't you lecture me" are you struggling with? Warren -talk- 22:47, 12 April 2009 (UTC)

A) You don't get to tell me what to do, B) all editors are expected to adhere to Wikipedia's standards, and C) are you trying to get blocked? MFNickster (talk) 22:50, 12 April 2009 (UTC)

To paraphrase a great Scottish engineer, "Aye... and if my grandmother had ~~wheels~~ a BSD subsystem, she'd be a ~~wagon~~ Unix-based operating system." While this discussion has been fascinating, please stop feeding the troll. AlistairMcMillan (talk) 03:22, 13 April 2009 (UTC)

Gladly. The thing is, I'm not convinced that if we ignore him, he'll go away. MFNickster (talk) 04:04, 13 April 2009 (UTC)

They all go away eventually, MFNickster. Surely you've been observing Wikipedia long enough to know that. Warren -talk- 12:06, 13 April 2009 (UTC)

my windows system has cygwin, I guess it's a unix-based operating system, and my linux system has wine and mono, so I guess it's a windows-based operating system. I think the fundamental issue is in trying to state that a complex, multi-layered, multi-standard operating system is "based on" one and only one of those layers, in a mutually exclusive sense. it's basically a lie by omission, and it's certainly a simplistic, inaccurate way to represent any modern system, particularly if the supposed base layer is neither the core kernel and hardware-controlling driver system, nor the interface that most of the application software is written for.

an accurate description would be that osx is based on many systems, bsd as a guest of mach/iokit being one of them. 70.50.178.185 (talk) 22:45, 13 April 2009 (UTC)

Boy, those wiley Apple engineers sure snowed those Open Group guys! MFNickster (talk) 22:53, 13 April 2009 (UTC)

apple doesn't say that osx is based on unix and nothing else. that "based on unix and only unix" insistence seems to be a wikipedia-specific thing. here are some quotes from apple:

"The fundamental services and primitives of the Mac OS X kernel are based on Mach 3.0." [32]

"Mac OS X is based on Mach and BSD." [33]

"Based on Mach 2.5 and BSD 4.4, this operating system is incredibly stable and scalable." [34]

"Kernel based on Mach 3.0 UNIX-like foundation" [35] (??)

"Mac OS X is based on the Mach 3.0 microkernel, designed by Carnegie Mellon University, and later adapted to the Power Macintosh by Apple and the Open Software Foundation Research Institute (now part of Silicomp)." [36] 70.50.178.185 (talk) 23:15, 13 April 2009 (UTC)

At the risk of further wearying the other editors, maybe it's time for a car analogy...

Say you are building an ambulance that you're going to sell, and you start with a Ford E-250 van. You spec out the gear you need to haul in back. Some, like the lights and airbags, uses the features of the van (BSD/GNU tools). Other stuff, like the stretchers and EKGs, doesn't rely on the features of the van at all other than transport (Cocoa/Carbon/Java), and yet other stuff, like the decals and siren, is just outward appearance (Aqua).

Since your van won't haul everything very well as is, you replace the motor (BSD kernel) with a Dodge engine (Mach), but you make it fit the existing Ford drivetrain (XNU). Oh, and now it runs on diesel (I/O Kit) rather than regular gas (traditional Unix drivers).

Oh, and since some hospitals want to outfit their own ambulances with custom gear, you offer to provide just the base van with modified drivetrain, diesel engine, and mounting points for lights etc. (Darwin).

Now, your argument is like saying that the ambulance is no longer based on a Ford E-250 van, because that's only one part of the whole package. It would be a lie by omission if you don't mention the Dodge parts and the stretchers and lights and EKGs. MFNickster (talk) 01:06, 14 April 2009 (UTC)

mach was always intended as its own kernel, it's not a runtime that mutated into a kernel, and osx is based on mach, it always has been. osx was never based on a bsd kernel, only a bsd layer as a guest on mach. so the analogy is false, the ambulance (osx) started as a dodge, nothing changed from the beginning of this project. also, the analogy is inconsistent in that the kernel was represented as an entire base vehicle when it was bsd, but it was only the engine when it came to switching kernels. the role-reversal scenario should have mach becoming everything that bsd represented, and bsd becoming whatever portion mach represented. also, if the only argument in favor of a mutually exclusive "unix based" claim is historical, and the present state of osx wouldn't support that claim, then it should be written in a past tense. 70.50.178.185 (talk) 01:55, 14 April 2009 (UTC)

No analogy is perfect, but I consider this usage of "based on" to be an exact parallel, meaning "we took $existing_thing and changed some things, added some things on top, but the basic design, operation, and most of the parts of $existing_thing are the same." MFNickster (talk) 02:09, 14 April 2009 (UTC)

mach is a separate system from bsd, it's not a fork. it's a clean-room project that, like almost all kernels, began as a guest on something rather than starting as raw opcodes stored into rom chips. mach is its own system, you can boot mach without anything related to bsd or unix. osx just happens to use a bsd guest layer to implement some things, but it's not that mach and bsd are one in the same, it's a coincidence. also, this is a historical note about mach, not a fact about the configuration of osx. 70.50.178.185 (talk) 02:41, 14 April 2009 (UTC)

The evidence suggests you're simply wrong about this. There is plenty of info here illustrating that Mach was conceived as a complete OS, not just a kernel - it started as a variant of 4.3BSD Unix in which the kernel was split into a microkernel and a user-space emulation layer that handled the high-level kernel functionality. It was hoped that those functions could be replaced by smaller independent processes (a la GNU Hurd), and even host other OS personalities. But in the beginning, it was a Unix OS. MFNickster (talk) 02:48, 14 April 2009 (UTC)

that's true that the first mach guest was intended to be a unix system, but I don't see how that makes mach unix based, and I certainly don't see how that historical note makes it accurate to forever refer to any system running on mach as "unix based." also, according to wikipedia's article about mach, it's based on a kernel called the accent kernel that had absolutely nothing to do with unix. 70.50.178.185 (talk) 03:01, 14 April 2009 (UTC)

Did you READ that article? Toward the end, it says: "The new system would use Accent's ports system within a Unix kernel, creating the famed Mach kernel." MFNickster (talk) 03:06, 14 April 2009 (UTC)

yes, that doesn't conflict with either the assertion that accent had nothing to do with unix, or the assertion that mach's intended and literal role was as a non-unix kernel playing host to a unix guest. microkernels were conceived and touted as hypervisors to be a platform-neutral host to multiple guest operating systems and completely separate services. that is the only point of a microkernel, in fact. using a microkernel to host a single guest is pointless. 70.50.178.185 (talk) 03:16, 14 April 2009 (UTC)

It specifically says that Mach was intended to be the low-level kernel in a UNIX system. This is like banging my head against a wall-- go do your homework, then come back and discuss it. MFNickster (talk) 03:26, 14 April 2009 (UTC)

mach's intended and literal role was as a non-unix kernel playing host to a unix guest. the unix guest wasn't even intended to run at kernel level. unix was supposed to begin in a privilege-separated module, a guest process. apple have eliminated mach's original microkernel design and mutated it into something more like a modular monolithic kernel, with its drivers living in kernel space. so the unix guest lives in the kernel address space, and that somewhat confuses people. mach itself remains completely free of unix, though. unix still begins only as a separate guest that doesn't interface directly with the machine, but for performance reasons, the guest isn't isolated in its own address space on apple's version of mach. the facts are that mach does not contain or provide anything related to unix, it's not a fork of unix code, it can boot without a unix guest, it can be used as a host for non-unix guests, it's based on the accent kernel that had nothing to do with unix, it is not unix. it has a connection to unix in that its intended purpose was to host a unix platform, but it isn't based on unix in any way. you could go make up and write your own non-unix system to run on mach, it would host that equally well because nothing about its design is unix-related. you could even host a windows guest on mach. mach is very similar in concept to the xen hypervisor. 70.50.178.185 (talk) 13:34, 14 April 2009 (UTC)

In theory, yes; in practice, nobody has done anything significant with Mach but build Unix systems on it. As surely as MkLinux was "microkernel Linux," the Mach OS was "microkernel BSD." MFNickster (talk) 13:58, 14 April 2009 (UTC)

well there aren't a lot of useful alternatives to hosting unix/unix-like systems, but either way, hosting unix doesn't make it unix, or unix based. originally, bsd on mach was like cygwin on windows, except that mach is a tiny platform compared to windows. the configuration in osx is true to the original, except that address space separation has been removed. 70.50.178.185 (talk) 14:14, 14 April 2009 (UTC)

Your fucking delusional mate. So if BSD/Mach is the equivalent of Cygwin/Windows, then Windows was developed as a replacement kernel for Cygwin? And again Mac OS X doesn't run Mach. If you compile the Mach kernel and try to use it as the Mac OS X kernel, it ain't gonna work. Everything depends on the BSD code in the kernel. EVERYTHING. AlistairMcMillan (talk) 17:01, 14 April 2009 (UTC)

mach works without bsd, bsd doesn't work without mach. you could even run mklinux and osx's bsd layer at the same time on mach. also, again, the cygwin analog is to boot osx on cygwin/windows by running the core services on cygwin instead of bsd, and then running the other non-unix-related 95% of apple's gui software on that. you're not addressing a meaningful scenario when you address a version where you switch from mach/bsd to windows/cygwin and you drop the 90% of osx that runs on top of mach and bsd. 70.50.178.185 (talk) 19:30, 14 April 2009 (UTC)

Please read this slowly.

The Mac OS X kernel is XNU. The Mac OS X kernel is not Mach. XNU is Mach and BSD. Mach was developed as a replacement kernel for BSD. BSD is definitely UNIX. Mach is arguably UNIX. AlistairMcMillan (talk) 01:57, 14 April 2009 (UTC)

mach is the kernel. bsd is a layer in a driver on top of it. the bsd layer doesn't interface with the underlying machine in any way, it interfaces exclusively with mach. you can't develop bsd-level drivers on osx. apple confirms all of this. 70.50.178.185 (talk) 02:41, 14 April 2009 (UTC)

You need to do your homework. Apple's sources make it clear that Mach is not the kernel; XNU is the entire kernel environment. It is a combination of Mach, BSD and I/O Kit functionality. It is a hybrid kernel. The BSD layer is not a driver, it is part of the kernel. Why is this so hard for you to grasp? MFNickster (talk) 02:12, 15 April 2009 (UTC)

apple removed mach address separation for performance reasons, so layers immediately on top of mach now live in the kernel address space. the fact remains that the bsd layer is on top of mach, mach doesn't depend on it, it is in a mach module, mach could host several such modules at once, it interfaces with mach and iokit but not directly with the machine, and it could easily be address separated, though, at a performance cost. apple explicitly says the same:

"The fundamental services and primitives of the Mac OS X kernel are based on Mach 3.0." "Mach 3.0 was originally conceived as a simple, extensible, communications microkernel. It is capable of running as a stand–alone kernel, with other traditional operating-system services such as I/O, file systems, and networking stacks running as user-mode servers. However, in Mac OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks." "Mac OS X processes and POSIX threads (pthreads) are implemented on top of Mach tasks and threads, respectively." "Mach is responsible for taking a requested virtual address and assigning it a corresponding location in physical memory. It does so through demand paging." [37]

"Mac OS X provides many benefits to the Macintosh user and developer communities. These benefits include improved reliability and performance, enhanced networking features, an object-based system programming interface, and increased support for industry standards." (note: unix isn't oo) "Both Darwin and Mac OS X include the BSD command-line application environment; however, in Mac OS X, use of environment is not required, and thus it is hidden from the user unless they choose to access it." "Darwin technology is based on BSD, Mach 3.0, and Apple technologies." (note: not just unix) "Because Mac OS X contains three basic components (Mach, BSD, and the I/O Kit), there are also frequently as many as three APIs for certain key operations." (not just unix) "Above the Mach layer, the BSD layer provides “OS personality” APIs and services." "The I/O Kit provides a framework for simplified driver development, supporting many categories of devices.The I/O Kit features an object-oriented I/O architecture implemented in a restricted subset of C++." [38]

"There are two general types of I/O Kit developers, and this document tries to be useful to both. The first type is the developer creating a device driver that is to be resident in the kernel; the second type is the application developer who is using an I/O Kit device interface to communicate with hardware." "Once you’ve absorbed the information in I/O Kit Fundamentals, you should be able to forge ahead and actually create a device driver." [39]

"Kernel-resident drivers have full access to kernel programming interfaces. However, because of their low level of operation, drivers should use only Mach calls and not BSD calls." "The I/O Kit encompasses dozens of C++ classes and is itself an extension of the libkern C++ library, the foundation for loadable kernel modules." [40]

"You might have developed device drivers for other platforms—Mac OS 9, perhaps, or BSD or another flavor of UNIX. One thing you’ll discover reading this document is how different the approach is with the I/O Kit." (note: implies that the kernel is not a flavor of unix, and is very different from flavors of unix) "The I/O Kit’s object-oriented programming model is implemented in a restricted subset of C++." [41]

"Mac OS X is based on the Mach 3.0 microkernel, designed by Carnegie Mellon University, and later adapted to the Power Macintosh by Apple and the Open Software Foundation Research Institute (now part of Silicomp). This was known as osfmk, and was part of MkLinux (http://www.mklinux.org). Later, this and code from OSF’s commercial development efforts were incorporated into Darwin’s kernel." [42]

"Mac OS X is based on Mach and BSD." "BSD–based and Mach–based operating systems contain legacy functions designed for basic single-processor synchronization." "If you are porting legacy code from earlier Mach–based or BSD–based operating systems, you must find an alternate means of providing synchronization." (suggests that mach-based and bsd-based are separate, and mutually exclusive) [43] 65.95.194.188 (talk) 15:36, 15 April 2009 (UTC)

Also about the point that IO/Kit drivers are not UNIX drivers. There is NO standard for UNIX drivers. Every UNIX operating systems has different drivers. AlistairMcMillan (talk) 01:57, 14 April 2009 (UTC)

kernels and drivers can be based on the unix programming standard. that is, ansi C, posix, and a number of other apis. linux is a good example. though, if your assertion is true then no kernel can be a unix kernel, and whether or not a system is unix based would presumably be a matter of whether the application-level software is based on unix. a tiny, tiny portion of apple's application code is unix-compliant. only the portion of the core services that interact with the bsd layer, which is even a minority of the core services. 70.50.178.185 (talk) 02:41, 14 April 2009 (UTC)

Also about the endless comparisons to Cygwin on Windows. I think I said before. Remove Cygwin from a Windows PC and you still have a working PC. Remove the BSD side of the XNU kernel and you have a machine that doesn't even boot. The comparison is frankly pathetic. A similar comparison would be suggesting that Microsoft might be considering removing Win32 from Windows 7. Equally unlikely. AlistairMcMillan (talk) 01:57, 14 April 2009 (UTC)

microsoft does categorize the windows api as deprecated, and they're moving toward a design where .NET is the central programming interface. in fact, it's probably already the case that saying windows is "based on the win32 api" is somewhat inaccurate, though, nowhere near as much so as saying that osx is "unix based," because osx bases a good portion of its runtime on mach specifics and other non-unix designs, where .NET is still primarily based on win32. also, a fair analogy involving cygwin would be to run apple's runtime and application software on top of it, and then to claim that the operating system as a whole is only "unix based." removing cygwin would break apple's lowest runtime layer and therefore anything that depends on that layer, but it wouldn't break windows, just like removing the bsd layer from osx would break the same tiny but critical portion of apple's application code, but not mach, because mach is a separate system from bsd and is a layer below the bsd layer. 70.50.178.185 (talk) 02:41, 14 April 2009 (UTC)

Microsoft does NOT categorise the Windows API as deprecated. Windows 7 includes improvements to the Windows API. The vast majority of Windows itself is written using the Windows API. The .NET framework is something that sits on top of Windows (like Cygwin sits on top of Windows, unlike BSD which is a core part of Mac OS X). If you removed the .NET framework Windows still runs perfectly fine (like Windows runs perfectly fine if you remove Cygwin, unlike Mac OS X where if you remove BSD the whole damn thing disnae work nay mare). AlistairMcMillan (talk) 17:01, 14 April 2009 (UTC)

microsoft recommends developing all new software on .NET, and a fair bit of windows 7 uses .NET. the .NET initiative is a massive effort across microsoft to eventually move the entire windows platform over to .NET, even the kernel. the concept is that it would eliminate all memory corruption bugs, which would also eliminate most security issues, and it would eventually even obviate the need for address spaces, low level privilege separation, hardware virtualization, and probably a majority of the circuits and power consumption of an x86 cpu. portions of .NET are already based on interfaces that aren't a part of the win32 api, but you're right that most of .NET is still based on win32, and a minority of windows 7 is based on .NET. if microsoft did eventually reach a point where a little over 50% of .NET was based on non-win32 interfaces, then .NET would be roughly as win32-based as apple's core services are based on bsd. also, in that case, if windows continued to expose win32, but almost all of its application software was based on .NET, then windows would be roughly as win32-based as osx is unix based. 70.50.178.185 (talk) 19:30, 14 April 2009 (UTC)

Everyone should realize now that this ridiculous discussion is 88 kilobytes long, that's 13,000 words. This is even worse than the "X not ten" one earlier. Dravick (talk) 12:59, 14 April 2009 (UTC)

Time for a vacation. :-P MFNickster (talk) 13:58, 14 April 2009 (UTC)

Time to stop feeding the troll. AlistairMcMillan (talk) 17:01, 14 April 2009 (UTC)

I'm done. The article isn't going to be changed to reflect this entirely unsupported opinion. Our anonymous friend is either taking the piss or incredibly badly informed. AlistairMcMillan (talk) 02:34, 15 April 2009 (UTC)

Yeah, I've also got to stop letting him bait me. I'm officially on vacation now. MFNickster (talk) 02:59, 15 April 2009 (UTC)

so to condense, apple says:

"The fundamental services and primitives of the Mac OS X kernel are based on Mach 3.0." [44]

"Mac OS X processes and POSIX threads (pthreads) are implemented on top of Mach tasks and threads, respectively." [45]

"Mac OS X is based on the Mach 3.0 microkernel" [46]

"Mac OS X is based on Mach and BSD." [47]

"Both Darwin and Mac OS X include the BSD command-line application environment; however, in Mac OS X, use of environment is not required, and thus it is hidden from the user unless they choose to access it." [48]

"Above the Mach layer, the BSD layer provides “OS personality” APIs and services." [49]

the insistence that wikipedia's introduction must present osx as exclusively "unix based" is therefore in direct conflict with referenced statements from apple. the point was made that OR isn't relevant, even if it is logical and provable, and that would also apply to the claim that apple is mistaken, and that the historical and/or technical research by a wikipedia author has led to the conclusion that osx is exclusively unix based. also, the "only unix based" argument supposes a subjective definition of based that is also based on OR rather than a statement from a reliable source. so in short, rather than continuing to argue the observable facts of how osx is configured, I would argue that this article should simply defer to apple and present the complete set of components that apple says osx is based on, rather than cherry picking based on OR and introducing osx as exclusively unix based. if there are no objections to this, I intend to move forward with either signing up for an account (and grieving having to do so) to modify the introduction, or to simply contact an administrator for assistance. 70.50.133.21 (talk) 15:26, 18 April 2009 (UTC)

Please, just go away. Dravick (talk) 17:41, 18 April 2009 (UTC)

If you can't handle talking to him, then leave. No one is forcing you to participate. Why are you here if you don't like talking about Mac OS X?--Validbanks 34 (talk) 08:23, 14 September 2009 (UTC)

Section break

... but the endless discussion was not over

the article currently states:

Mac OS X, whose "X" represents the Roman numeral for "10" and is a prominent part of its brand identity, is a Unix-based operating system,^[1] built on technologies developed at NeXT between the second half of the 1980s and Apple's purchase of the company in early 1996. Its sixth and most recent version, Mac OS X v10.5 is certified UNIX 03 while running on Intel processors.

"Unix" is unnecessarily vague in the first sentence, given that it's referring specifically to bsd, not the general UNIX certification. I propose that saying it is based on bsd would be more informative, and that is how apple often describes it.[50][51] also, in addition to bsd, apple say in numerous documents that osx is also based on mach and their own technologies.[52][53][54][55] I would also assert, on a note relating only to quality, that "built on technologies developed at NeXT between the second half of the 1980s and Apple's purchase of the company in early 1996" is unnecessarily detailed and verbose for this section, and that it belongs in the history section. so, based on the above, I propose changing the first sentence to:

Mac OS X, whose "X" represents the Roman numeral for "10" and is a prominent part of its brand identity, is based on BSD, Mach 3.0, and Apple technologies.^[3]^[4]^[5]^[6]

please note that "is based on BSD, Mach 3.0, and Apple technologies" is a verbatim quote, the whole sentence being "Darwin technology is based on BSD, Mach 3.0, and Apple technologies."[56] if there is any dispute relating to darwin vs osx, please note "Mac OS X is based on the Mach 3.0 microkernel."[57] "Mac OS X is based on Mach and BSD."[58] I chose "is based on BSD, Mach 3.0, and Apple technologies" because it is a direct quote from apple listing the 3 major categories of technology that osx is based on, and my hope is that quoting apple directly can prevent any controversy about the ordering or phrasing of the components. (I would personally place Mach first if I were going to quote myself in lieu of quoting apple)

also, regarding the second sentence which states that osx has passed unix certification, I'd like to make it clear that I don't deny that fact, and I don't aim to remove it. that being said, I do have two objections to the sentence. the first is that it says "is certified UNIX," and I propose changing that to move away from language suggesting that osx "is UNIX" which wouldn't seem to be the intended purpose of the statement or something supported by the reference or apple's own comments. though, again, the point that osx provides an environment that meets unix certification is not in dispute, and is not something I'm trying to delete. there is also the fact that apple says "Both Darwin and Mac OS X include the BSD command-line application environment; however, in Mac OS X, use of environment is not required, and thus it is hidden from the user unless they choose to access it."[59] I think this is directly relevant if osx's unix environment is going to be mentioned. the key points being that use of the environment is not required, and that it is hidden by default. apple's quote would seem to be too long to be used verbatim, so here's what I propose:

In its sixth and most recent version, Mac OS X v10.5, the BSD layer passes UNIX 03 certification while running on Intel processors,^[1] though, use of the environment is not required, and it is hidden by default.^[7]

thus, my proposal is to change:

Mac OS X, whose "X" represents the Roman numeral for "10" and is a prominent part of its brand identity, is a Unix-based operating system,^[1] built on technologies developed at NeXT between the second half of the 1980s and Apple's purchase of the company in early 1996. Its sixth and most recent version, Mac OS X v10.5 is certified UNIX 03 while running on Intel processors.

to

Mac OS X, whose "X" represents the Roman numeral for "10" and is a prominent part of its brand identity, is based on BSD, Mach 3.0, and Apple technologies.^[8]^[9]^[10]^[11] In its sixth and most recent version, Mac OS X v10.5, the BSD layer passes UNIX 03 certification while running on Intel processors,^[1] though, use of the environment is not required, and it is hidden by default.^[12]

70.50.133.205 (talk) 13:59, 22 April 2009 (UTC)

A consensus has been reached, and while not immutable, it is not in favor of your opinion at the moment. Your insistence that Mac OS X is not UNIX-based is not shared by anyone else and flirts with original research. I will also quote from WP:Verifiability, "The threshold for inclusion in Wikipedia is verifiability, not truth." Dravick (talk) 14:50, 22 April 2009 (UTC)

given that my proposed changes consist of adding statements by apple, verbatim/word-for-word, with direct references to apple.com, can you back any of that up? -无名氏- 15:22, 22 April 2009 (UTC)

Your proposed change hinders understandability, which is a very bad thing for a lead section, as outlined by the Wikipedia:Lead section guideline. The text needs to be easily digestible by people who have never heard of Mac OS X before, and that, by necessity, means leaving out some of the gory details. There's nothing factually incorrect with what is said now in the lead... consider, for example, that NeXT owns the trademarks on "Objective-C", and that the Cocoa API was a NeXT invention, and that just about everything in Mac OS X that wasn't ported from Mac OS 9 is built on these technologies. Warren -talk- 19:56, 22 April 2009 (UTC)

I agree, almost all application-level software in osx other than the internals of their objective-C runtime is based on nextstep. that's part of what I've been arguing, and part of why I strongly object to generalized phrasing that suggests osx is exclusively unix based. I consider it a real compromise to truncate the 95% of osx that is based on objective-C down to a verbatim quote from apple saying "and apple technologies," which I did link to the nextstep article. I would certainly have no objection to making/keeping the nextstep mention more elaborate, so long as the vague and misleading "unix based" marketing is clarified. -无名氏- 20:44, 22 April 2009 (UTC)

Yes, there's BSD and Mach and I/O Kit underneath -- this is duly noted by describing Mac OS X as "Unix-based", though Unix-like would be pretty accurate for versions prior to 10.5 on Intel. Warren -talk- 19:56, 22 April 2009 (UTC)

"Unix-based" is a vague and uninformative way of saying it's based on bsd, but mach and i/o kit have nothing to do with the unix specification. especially i/o kit, it has absolutely nothing to do with unix in any conceivable way. I just left out i/o kit to reduce the appearance of added complexity, but I would have no objection to explicitly mentioning it, and there are many references on apple.com to back up stating i/o as one of the base components of osx. -无名氏- 20:44, 22 April 2009 (UTC)

But what makes Mac OS X what it is, both in terms of what developers and end-users see, is largely due to the NeXT contribution. That's why it gets more prominence in the lead. Warren -talk- 19:56, 22 April 2009 (UTC)

right, and that is my point exactly. if anything, "nextstep based" would be the closest-to-sensible generalization, but I would still prefer to explicitly mention bsd and mach, as they are separate and critical components. -无名氏- 20:44, 22 April 2009 (UTC)

"...however, in Mac OS X, use of environment is not required, and thus it is hidden from the user..." They aren't talking about BSD within the operating system as a whole. They are talking about the BSD command-line application environment i.e. Terminal.app. The Terminal is not required and hidden from the user, not BSD as a whole. AlistairMcMillan (talk) 20:34, 22 April 2009 (UTC)

according to the single unix specification, that command-line environment is unix. unix certification requires providing a terminal with a particular type of interactive shell and a particular set of shell programs, plus an ANSI C compiler with posix and a few other apis. the gnu C compiler and other gnu utilities probably represent more lines of code supporting the unix certification than the bsd layer. either way, though, the certified unix environment lives in the terminal, and is hidden by default, according to apple. -无名氏- 20:50, 22 April 2009 (UTC)

Absolute nonsense. Firstly you do understand that when Apple say "hidden" they just mean that Terminal.app is located in "/Applications/Utilities" instead of "/Applications". Secondly you said if your changes don't go in the article you're going to speak to an admin, well I am an admin, and I'm the one who locked down the article specifically to stop your edits. Please understand, whether you are just here to troll or whether you really believe this nonsense, you don't know what you are talking about and your changes aren't going into the article. All the evidence points to your being utterly wrong. Case closed. AlistairMcMillan (talk) 23:19, 22 April 2009 (UTC)

yes, I'm aware that you're an administrator, that you falsely claimed that my edits were vandalism, which is a very strict definition that my edits clearly don't meet, and that you locked the page in order to prevent editing by me. you broke the rules, and also, in general, you shouldn't be both edit warring/owning/hawking over an article, and blocking other users from editing the article as a solution to a conflict in which you are personally engaged, as that is a massive conflict of interest and ethics. however, this isn't the forum for a debate about your abuse of power. your threats and demands are meaningless, your status as an administrator has no bearing on this discussion, I don't intend to discuss it further in this location, and I don't intend to deal with that issue at all until I have to.

on the actual subject of this discussion, I would prefer to stick to verbatim quotes from referenced sources, in this case apple, rather than conducting OR and speculating about whether apple's statement is accurate. according to apple, "Both Darwin and Mac OS X include the BSD command-line application environment; however, in Mac OS X, use of environment is not required, and thus it is hidden from the user unless they choose to access it."[60] I contend that apple is more authoritative than you or me, and that the statement by apple that use of their unix environment is not required, and that it is hidden from the user, is pertinent to the article and to the point that osx provides a certified unix environment.

in short, is there a reason why it's encyclopedic to mention that osx provides a unix environment, but quoting apple's statement that it's hidden by default is somehow not encyclopedic? -无名氏- 00:41, 23 April 2009 (UTC)

Back from vacation, I guess. Without arguing further, I'll just point out that we have given referenced verbatim quotes from Apple supporting the other side of the argument as well. MFNickster (talk) 01:04, 23 April 2009 (UTC)

my assertion is that apple states at least 3 bases of osx in a variety of places, and that it is not informative or useful to cherry pick and to state only one of them. an inclusive pattern is consistent with all quotes and references, and it would only conflict with a theoretical quote that explicitly said bsd/unix is the exclusive base of osx. on the other hand, any exclusive pattern (such as the current statement) will conflict with solid references. -无名氏- 02:08, 23 April 2009 (UTC)

Or, you could just accept the possibility (as I have) that Mac OS X is based on Unix and on Mach and on BSD and on I/O Kit. You said above that saying "based on Unix" is unnecessarily vague. Not so; it is more general and more inclusive, and conveys the family history and design of the core OS very well. MFNickster (talk) 02:38, 23 April 2009 (UTC)

that's a great way of stating the basis of my point: Mac OS X is based on Unix and on Mach and on BSD and on I/O Kit. also, 95% of osx is objective-C code that has nothing to do with unix. I'm not proposing that unix be excluded, I'm proposing that apple's other referenced statements about the basis of osx should not be excluded. "unix" alone does not encompass the 3 or more systems that apple says osx is based on, and in fact, it doesn't encompass any specific system. you can't get the unix source code because it doesn't exist, you can't ask for a copy of unix any more than you can ask for a copy of posix. being "unix-based" would presumably have to mean that something makes some use of an unspecified implementation of the unix standard, but it is so vague and generalized that it's hard to derive any specific meaning from the phrase. on the other hand, saying "based on bsd and passes unix certification" would be very specific and informative. but even if "based on unix" were a meaningful statement with a specific meaning, mentioning only "unix" is a cherry pick and it is misleading, because while bsd is vaguely encompassed by the phrase "unix," the other components have at most some historical relation to unix-conformant systems in their intended purposes or environments, but are not implementations of unix, or forks of implementations of unix. i/o kit and nextstep's massive objective-C libraries in particular have nothing to do with unix in any way, historically or otherwise. also, it is telling that the reference(s) for "unix based" are marketing hype full of phrases like "the amazing power of," and the countless references for clear and accurate statements like "based on bsd, mach, and apple technologies" are far more encyclopedic references that state explicit and incontrovertible facts about the system. -无名氏- 15:40, 23 April 2009 (UTC)

In short the reason this shouldn't be mentioned is that you are confused, and are failing to grasp what Apple are talking about. When they are talking about the BSD command-line application environment they are talking about the application called Terminal. They are NOT talking about the BSD portion of the kernel. I can't emphasis this enough. They are talking about hiding the Terminal application from the user (which basically just means putting Terminal in /Applications/Utilities instead of /Application). They are saying that using the Terminal application isn't a requirement. They are NOT talking about the BSD portion of the kernel. AlistairMcMillan (talk) 12:27, 23 April 2009 (UTC)

my assertion is that it is pertinent to the statement about unix certification, not the base of the kernel/system. the component that meets unix certification is the terminal/command-line. that is all that is relevant to unix certification, and if you removed the GNU utilities (sh, ls, find, ps, cc etc..) then osx would not be certifiable anymore, whether bsd code was in the kernel or not. in fact, the bsd portion of the kernel has absolutely nothing to do with unix certification. you could just as easily make C/posix work on top of any other subsystem and get unix certification, so long as your C/posix compiler worked perfectly, and you compiled an interactive shell and shell programs on it, and they worked perfectly. -无名氏- 15:40, 23 April 2009 (UTC)

(1) the sh , ls, find, etc utilities in Mac OS X are not based on GNU code, they are based on BSD code. (2) Unix certification does not depend solely on whether an OS has a Unixy terminal/command-line, it depends on a great deal more, including for one example threads which sure as shit depend on the BSD code in the kernel. (3) Mac OS X sure as hell is not 95% Objective-C code. Please stop wasting your own and our time with this argument that isn't actually going anywhere. You haven't convinced a single other editor with this weeks long argument. Take a hint. AlistairMcMillan (talk) 18:44, 23 April 2009 (UTC)

1) osx sh is gnu bash, osx cc is gcc, which are probably the 2 most important command-line components in unix certification. though, either way, the command-line tools and C/posix compiler that define unix aren't even a part of the bsd layer. the bsd layer only serves to provide some services like filesystem support that aren't a part of unix. also, like apple says, use of the command line environment (unix) is not required and it is "hidden" (their word) by default.

2) unix certification requires the command line tools (sh, cc, ls, find, ps, awk, etc.) and that cc provides an ANSI C and POSIX compliant interface. in fact, osx's command-line environment doesn't meet the unix specification by default, without xcode. also, posix threading in darwin/osx is provided by mach, not the bsd layer. quoting apple: "Mac OS X processes and POSIX threads (pthreads) are implemented on top of Mach tasks and threads, respectively."[61] keep in mind that the bsd layer doesn't interface directly with the machine, so it really can't provide anything but user-level services that boil down to rearranging bytes, like taking a block device and decoding a filesystem structure.

3) nextstep and cocoa are MASSIVE projects compared to mach, i/o kit, and the bsd/gnu components. read about cocoa some time, it's a huge platform, and a respectably modern and complete oo system in the same league as java, qt, and .NET. also, all of apple's gui software is based on either carbon or cocoa. in stating 95%, I'm referring not only to the obj-C runtime and programming interfaces, but the extensive gui projects that apple has built on them, like itunes and ilife. also, if you consider that the core kernel is mach and all of the drivers are i/o kit drivers with no code related to bsd or the unix standard, the actual portion of lines of code in osx that have anything to do with bsd or unix is very tiny. though, all of this is moot, the only question is what the references say, and they say that use of unix in osx is not necessary and it is hidden by default, and that osx is based on bsd, mach, and apple technologies. -无名氏- 02:10, 24 April 2009 (UTC)

No, again, Apple's sources say the Unix command line is not necessary and hidden by default. And fair enough you are right about bash and cc, they are GNU. But the GNU commands are few and far between in a sea of BSD commands. AlistairMcMillan (talk) 02:32, 24 April 2009 (UTC)

like you said (I think) above: a kernel, bsd or not, can't be unix either way. also, apple's gui certainly has nothing to do with meeting the unix specification, so that command-line system is the basis of the unix certification. you could even have several unix-conformant command-line systems in a single OS, or several unix-like environments where only a particular one was certified. I agree that the vast majority of terminal commands are bsd, not gnu. though, even though "gnu's not unix," the command line environment definitely does meet unix certification if xcode is installed. given that the command line is the basis of the unix certification, and that apple says it's not necessary and is hidden by default, it doesn't seem accurate to describe it as what osx "is" or to depict the command line as central to osx. also, shouldn't there be a mention of the fact that it's only unix conformant if xcode is installed? -无名氏- 03:00, 24 April 2009 (UTC)

Just to be clear, I am still against discussing this any further. I did respond first, but I tried to be as detached as possible and provided links why we considered the discussion closed. Also, AlistairMcMillan did not do anything wrong, the edits were indeed vandalism. In this awfully long discussion, we all reached a consensus, except for one participant. This participant then decided to do it his way and vandalized the page by edit-warring. This resulted in a page lock. Please understand this, until at least one reliable source states that "Mac OS X is not UNIX-based" or something similar, the page will not be changed. It does not matter whether Mac OS X is secretly not UNIX-based and deceived everyone except you or not. To change the page in agreement with your opinion, you need a reliable source that agrees with you; _you_ are not a reliable source, and you cannot use a source that does not agree with you as though it did. Until then, I still consider the discussion to be over, and any edit-warring will result in warnings or a ban, as usual. This is utterly pointless. Dravick (talk) 03:33, 23 April 2009 (UTC)

quote: "Vandalism is any addition, removal, or change of content made in a deliberate attempt to compromise the integrity of Wikipedia." "Any good-faith effort to improve the encyclopedia, even if misguided or ill-considered, is not vandalism. Even harmful edits that are not explicitly made in bad faith are not vandalism. For example, adding a controversial personal opinion to an article once is not vandalism; reinserting it despite multiple warnings is (however, edits/reverts over a content dispute are never vandalism, see WP:EW)." see Wikipedia:Vandalism. I didn't restore a reverted edit even once, I made two separate changes, based on talk.

I'm not proposing that the article be edited to reflect the opinion that "Mac OS X is not UNIX-based" and I don't need to provide references for the heading of this talk section. I'm proposing that apple's direct, explicit, referenced quotes like "Mac OS X is based on Mach" be included, in addition to clearly stating that one of the bases of osx is bsd/unix, and clearly stating that the command-line environment in osx meets unix certification. -无名氏- 15:40, 23 April 2009 (UTC)

The items you're proposing to add to the lead are already part of the article. You're taking issue with basically one statement that no one else seems to have an issue with. MFNickster (talk) 15:47, 23 April 2009 (UTC)

this isn't a question of how you or others feel about someone who questions osx's unix-ness proposing changes to the article, it's a question of accuracy. my assertion is that stating "osx is unix based" and omitting the other components at that point in the article is misleading. this is like saying "a hotdog is ash" is valid because you state in another section that "a hotdog is made of meat, water, flour, ash, and spices, and preservatives." -无名氏- 15:58, 23 April 2009 (UTC)

Well, then your argument is with Apple. MFNickster (talk) 16:08, 23 April 2009 (UTC)

not at all, apple states that osx is based on bsd/unix, mach, i/o kit, and nextstep. I don't deny any of that and I don't want to omit any of it. I want to include all of it. cherry picking and mentioning only one of apple's stated bases is in conflict with other statements by apple, and with basic informative/encyclopedic standards. particularly if the vague term "unix based" is to be the cherry pick, taken from advertising, where apple's white papers use the term bsd. -无名氏- 16:38, 23 April 2009 (UTC)

Right, but I disagree that it is inaccurate, misleading, or "cherry-picking." It's a sensible way to describe the low-level system in general, and it is supported by the references. "Unix-based" isn't "one of Apple's stated bases," it's the amalgamation of the kernel, system interfaces and userland tools - everything below the application frameworks. We've been over this and over it again, and no matter how much Darwin may differ from previous Unixes or NextStep, it is still undeniably the foundation of Mac OS X, it is derived from Unix code, and it's certified compliant. This is not controversial. Talk about making mountains out of molehills... MFNickster (talk) 17:36, 23 April 2009 (UTC)

your assertion that "unix based" encompasses mach, i/o kit, the bsd guest layer, darwin as a whole, and "apple technologies" is OR on your part, not something supported by the references, and it's just not accurate. the only references that even use the word unix are advertising papers, which isn't surprising given that unix is a standard rather than a specific tangible component like the bsd kernel or the gnu C compiler that can be copied into an operating system. the bsd layer isn't unix, it isn't even unix-conformant. it's a set of stacks that provide filesystem access and other features. the unix environment in osx, which isn't used by other components, is mainly a matter of gnu tools like sh and cc that have been adapted to comply with the unix specification, using mach, i/o kit and the bsd layer as a back end. in fact, one of the most important and fussy aspects of the unix specification is posix threads, and that is provided by mach, not the bsd layer. also, mach provides processes and inter-process communication, memory management, and a variety of features that are used to make ansi C and posix work. also, the executable format is a mach format, not a bsd format. though, all of this is moot, as any conclusions that you or I might draw are OR. what matters is the references, and whether you might think that unix summarizes everything, and I might think that nextstep represents enough of the system to be stated as the exclusive base, both of those conclusions are OR, and what is referenced is that apple states that osx is based on mach more than they mention any other component, and they also typically mention bsd by name rather than unix, plus i/o kit, nextstep, and "apple technologies." so whether we could agree that "unix" summarizes osx or not, that assessment means nothing, and isn't verifiable, unlike, for example, quoting apple's white paper that says darwin is based on "bsd, mach, and apple technologies". -无名氏- 18:08, 23 April 2009 (UTC)

I'm not arguing that Unix is the "exclusive base," but rather the inclusive base. Anyway, I'm going back on vacation, because no matter how many times and ways you are proven wrong, you keep insisting that your interpretation is the correct one. I recommend reading this and this. See you around! MFNickster (talk) 18:40, 23 April 2009 (UTC)

I'm not sure what axe you think I'm grinding. I use osx every day, I've worked with linux and other unix-like systems extensively for 15 years, I don't have a prejudice for or against osx or unix. I simply find the advertising slogan "unix based" to be less informative and useful than the more encyclopedic terms used in apple's white papers, and I find "is certified UNIX" to be an oddly loaded way of stating that osx's command line and C compiler meet unix certification. also, I'm more than happy to leave personal opinions out of the discussion and article, and to simply place a referenced quote from apple.com. the only opinion of mine that I'm defending, and I think this is supported by wikipedia's standards, is that accurate and informative statements from formal white papers by apple shouldn't be excluded in favor of an uninformative advertising slogan. it wouldn't be encyclopedic to quote "windows is preferred by most families" rather than "a 2005 study found that 92.7% of american households used windows based computers," if both were referenced from microsoft.com. -无名氏- 19:06, 23 April 2009 (UTC)

I've already pointed this out to you once, but I'll say it again in the hopes that you'll get it -- WP:LEAD expects lead sections to be very general and non-technical. What you're proposing is making the lead specific and detailed in a way that isn't going to be of immediate interest to people who want the most basic of overviews. The detail you want to include in the article is already there.... it just doesn't need to be in the lead section. If you have a personal dislike of "Unix-based" or "certified UNIX", that's a view you're welcome to have. But, like the folks who believe the article Linux should be renamed GNU/Linux, your view is a minority one. That doesn't stop neither you nor them from kicking up the dirt for weeks on end, but at some point you have to just back away, accept that a majority of editors believe the current, simpler description is sufficient, and move on to something more productive and less frustrating. Trust me on that one.

Also, I consider it impolite to break my comments up into sections and to sign my name multiple times, then put your comments between them; please don't do that again. It misrepresents how I presented my thoughts. Write your comments afterwards like the vast majority of Wikipedians do. Thanks. Warren -talk- 01:59, 24 April 2009 (UTC)

I wasn't trying to change anything about what you said, I'm sorry if you felt that way. -无名氏- 02:26, 24 April 2009 (UTC)

if "is based on bsd, mach, and apple technologies" is too complex then "unix based" could be scrapped for "mach based" or "nextstep based" or "based on a variety of technologies," or it could be scrapped entirely. "unix" does not include or cover mach, i/o kit, objective C, carbon/cocoa, apple's core services, or really even the bsd layer of the kernel, and other than a mistaken claim to the contrary, no reason has been presented for why it is preferable to any/all alternatives. also, "is certified UNIX" can be rephrased in a less loaded way without introducing any added complexity. also, why is the command-line environment's unix certification vital information, but the fact that apple says (paraphrasing) "its use is not required and it is hidden by default" is too complex and must be buried in another part of the article? isn't referring to "unix" less clear and simple than the simple statement that the environment is hidden by default? does the reader necessarily know what "unix" means, but not what "hidden" means? -无名氏- 02:26, 24 April 2009 (UTC)

Second section break

there is also the fact that osx alone doesn't meet the unix specification, it requires xcode or another package with a compliant C compiler. -无名氏- 15:06, 1 May 2009 (UTC)

Where did you find that requirement? Just curious. MFNickster (talk) 21:42, 1 May 2009 (UTC)

Shhh. Dravick (talk) 07:13, 2 May 2009 (UTC)

a cc command with the appropriate C/posix apis was one of the factors tested in the opengroup unix certification of osx because it's one of the requirements of the single unix specification. the tested system must have had xcode installed because The Mac OS X Xcode Tools package provides additional tools that you will need to install to round out your development environment. These are not part of the default installation, but are essential to you. They contain some of the most important tools, such as the compiler (gcc) and debugger (gdb).[62] -无名氏- 22:27, 1 May 2009 (UTC)

Damn, you've got us now. You're totally right and we're totally wrong.

If only Apple included a copy of Xcode and a compliant C compiler with every single copy of Mac OS X.

Oh wait... they do. AlistairMcMillan (talk) 13:25, 2 May 2009 (UTC)

I'm not saying the statement should be removed, I'm proposing that the statement be amended to mention that xcode must be installed, whether it's from the dvd or a free download. -无名氏- 14:19, 2 May 2009 (UTC)

They also questioned whether there was a Fortran compiler, to which the answer was NO. Where exactly does it say that a C compiler is a requirement? And understand I'm just asking out of curiousity. We've already told you repeatedly that your suggested change isn't going in the intro. AlistairMcMillan (talk) 16:23, 2 May 2009 (UTC)

unix 03 certification requires 4 standards, one of them is the C language V2 which includes posix, and another is the commands and utilities v4 which requires a cc command meeting the C language requirement. see the opengroup unix 03 certification guide. -无名氏- 18:07, 2 May 2009 (UTC)

So basically what you're aruging is that the lead section of Wikipedia's top-level article on Mac OS X needs to talk about how you have to install the optional developer tool package in order to be conformant with one of the four major sections of UNIX 03. Maybe you really care about this sort of thing, but I assure you, the vast majority of our readers who just want to learn a few basic things about this topic, do not. If you want to pop that information into the main body article, go for it. Just make sure you provide sources that explicitly say that the developer tools need to be installed for full UNIX 03 conformance. It just doesn't belong in the lead. Warren -talk- 21:47, 2 May 2009 (UTC)

maybe the mention of unix conformance specifics is overly technical. -无名氏- 22:49, 2 May 2009 (UTC)

I think there is little doubt that the certification Apple obtained is sufficient grounds to call Mac OS X "UNIX". However, there is far more to Mac OS X than that -- the Mach kernel, Aqua, Quartz etc. I think these items deserve to be at least mentioned in the introduction, as they make a huge difference (compare Mac OS X to OpenDarwin to see what I mean.) -Stian (talk) 18:27, 2 May 2009 (UTC)

Putting Quartz into the lead of this article makes about as much sense as mentioning GDI in the lead for Microsoft Windows. i.e. it makes no sense at all. Do you really, honestly believe that a non-technical person (i.e. the vast majority of Wikipedia's readers) really needs to read an arbitrary list of core operating system components in order to gain a basic, high-level understanding of what this thing called "Mac OS X" is? We have plenty of space in the encyclopedia for jargonesque names and highly-technical details about the architecture of the operating system... lead sections, however, should try to avoid such detail. Warren -talk- 21:31, 2 May 2009 (UTC)

aero would be more analogous to quartz, and it is mentioned in the introduction to the vista article, along with .NET, the windows api, dvd maker, DRM, "trustworthy computing," "longhorn," and more. what makes unix so vital and universally understood? in my experience, few people actually understand what the unix specification entails, including those asserting that it should be the only technology mention in the introduction to this article. -无名氏- 21:41, 2 May 2009 (UTC)

The Vista article is about a particular version of Windows, so the intro is used to explain what distinguishes Vista from previous versions of Windows. Don't compare that to this article which is about a series of operating systems. AlistairMcMillan (talk) 21:55, 2 May 2009 (UTC)

this is the article about mac os X, not a history of everything branded mac os. -无名氏- 21:58, 2 May 2009 (UTC)

Windows Vista is equivalent to Mac OS X v10.5. Windows NT is equivalent to Mac OS X. AlistairMcMillan (talk) 22:05, 2 May 2009 (UTC)

the point is that not all versions of windows contain the technology, so it doesn't belong in the article about the history of windows, but it is applicable and informative to mention it in a specific version or line that contains the technology. -无名氏- 22:47, 2 May 2009 (UTC)

Check your facts, 无名氏. Windows Aero is analogous to Aqua; Quartz is analogous to the Desktop Window Manager. Aero and Aqua are well-known and highly visible aspects of their respective operating systems and will be of interest to a wide swath of readers. Quartz and the DWM are implementation details, which will primarily be of interest to... well, for lack of a better word, nerds. Warren -talk- 22:23, 2 May 2009 (UTC)

I don't necessarily disagree, but beyond being a positive-sounding buzz word, "unix" is also not a term that is widely and specifically understood by laypersons. why not apply your quality standards to the unix specification? does the reader strongly need to know that osx has a shell interpreter, shell commands, and a posix conformant ansi C compiler? and would mentioning unix conformance mean that, or anything, to most readers? and is it so important that it should trump all other aspects of the operating system for being prominently mentioned in the introduction? -无名氏- 22:47, 2 May 2009 (UTC)

It's because there is a distinction between "UNIX" and "Unix-based": We can't, with 100% accuracy, call all of Mac OS X one or the other; an operating system either a "UNIX", or a "Unix-based" or "Unix-like" operating system. We need to use that particular four-letter word somewhere in the lead section because it is a high-level general categorization the operating system. You're right, the general reader doesn't need to know about what exactly "UNIX 03" means, but that's why we wikilink to the term instead of getting into detail. We wikilink to "operating system" for the same reason. Again, it comes down to describing the fundamentally important stuff (i.e. what it is) rather than the details of the implementation. Warren -talk- 00:46, 3 May 2009 (UTC)

but what makes unix more fundamentally important? what makes unix 03 conformance while running on intel processors more fundamentally important than what kernel it runs, or what language and framework the entire graphical system is written in, or the driving technologies behind most of the system such as cocoa? the unix conformant components in osx really have nothing to do with a normal user experience, or how developers normally write graphical programs or hardware drivers. literally, there is no overlap. apple seems to have made it their mission to completely wrap over C and posix with object oriented frameworks, and to provide graphical interfaces for everything the system can do, obviating the need for the unix command line as much as possible. I think they've done a great job, too. few mac programmers write in straight C and posix, few mac users know how to operate a unix command prompt, and those topics are all there is to the unix spec and certification. -无名氏- 02:33, 3 May 2009 (UTC)

For the third time -- please wrap your head around this -- it's the difference between providing a simple, a high-level overview, and discussing implementation details. We do the former in the lead section, and the latter in the main body text. As long as you insist on talking about POSIX, C compilers, object-oriented frameworks, etc., you aren't going to have anything at all to contribute to writing a lead section of an article about an operating system. You just aren't demonstrating the ability to take a biiiiiig step back away from being a nerd. I realise it's hard, but you MUST be able to do this if you're going to write good encyclopedia articles that meet our guidelines. Warren -talk- 12:53, 3 May 2009 (UTC)

your personal insinuations are inappropriate here. the topic is the subject matter, and on that subject, you've either missed or role reversed my point, because my point is the opposite of what you seem to think. I'm not arguing that the introduction should inform the reader of the details of what unix is and isn't. I'm saying the opposite: that it should be obvious that most readers will have no idea what unix is, that they wouldn't know or care what a bourne/posix shell and C/posix compiler are (which are all that unix is), that it isn't practical to try to inform the reader of these things in this article's introduction, and that unix is therefore not a sensible point to place massive and exclusive emphasis in the introduction. my point is that other components are better understood by the public, and that they play more central roles in osx.

in fact, you could remove anything related to unix from osx by reimplementing bsd's network and filesystem stacks, deleting the bsd module, deleting the command line/terminal, and making cocoa work on top of the new stacks, and all of that would go unnoticed by most users because it would have no effect on the graphical components (quartz, aqua, ilife, quicktime, itunes etc..) that make macs what they are.

I mean, making unix the central technology mention in the introduction is not only misleading, it's also a nerdy technical detail that isn't well understood and that has no bearing on the user experience for the vast majority of users. -无名氏- 16:46, 3 May 2009 (UTC)

Will this never end? Yes, Apple could replace the Unix layers with something else, and users would probably not notice. In fact, they did not - they implemented the UI on top of Unix. Your argument amounts to saying "It's not Unix-based because you could replace Unix as the base." MFNickster (talk) 17:14, 3 May 2009 (UTC)

bsd network and filesystem stacks are critical components in osx, and those are unix-esque in design, though not specifically conforming to or satisfying any part of the unix spec. also, the terminal and xcode together do conform to and satisfy the unix spec, and they have been certified. though, unlike the bsd stacks, they don't support the user experience in any way, and they could simply be deleted/omitted without affecting most users. in other words, the actual bourne shell and C/posix compiler that satisfy the unix standard aren't a part of the user experience at all, even as internals. in fact, the terminal is "hidden by default" and xcode isn't installed with osx by default.

so I'm not arguing that nothing in osx implements the unix standard or is unix related, or that unix therefore shouldn't be mentioned. my point is that the reader isn't likely to know anything about shell interpreters and C/posix compilers, or therefore what unix means, and my point is also that unix related designs are secondary in osx, with frameworks like cocoa and i/o kit being far more important than C/posix in the internals of the system, and with aqua/ilife/etc.. being the quintessence of the mac, with the unix-conformant command prompt being of no relevance for the vast majority of users.

so should the unix conformant terminal be mentioned? definitely somewhere, maybe even in the intro. should apple's own systems like carbon/cocoa/quartz/aqua/quicktime/ilife/etc.. be prominently mentioned in the intro? definitely, because unlike unix designs, they make the mac what it is. -无名氏- 18:54, 3 May 2009 (UTC)

^ ^a ^b ^c ^d ^e "Mac OS X for UNIX Users" (PDF). Apple Inc. January 6. Retrieved December 15 2008. {{cite web}}: Check date values in: |accessdate= and |date= (help); Unknown parameter |dateformat= ignored (help) Cite error: The named reference "osx_unix" was defined multiple times with different content (see the help page).
^ Mac OS X System Overview
^ [63]
^ [64]
^ [65]
^ [66]
^ [67]
^ [68]
^ [69]
^ [70]
^ [71]
^ [72]

[osx_unix-1] "Mac OS X for UNIX Users" (PDF). Apple Inc. January 6. Retrieved December 15 2008. {{cite web}}: Check date values in: |accessdate= and |date= (help); Unknown parameter |dateformat= ignored (help) Cite error: The named reference "osx_unix" was defined multiple times with different content (see the help page).

[2] Mac OS X System Overview

[3] [63]

[4] [64]

[5] [65]

[6] [66]

[7] [67]

[8] [68]

[9] [69]

[10] [70]

[11] [71]

[12] [72]

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]