Talk:MacOS

Proposal to end consistently re-occurring pronunciation issue

Long discussion on 'Proposal to end consistently re-occurring pronunciation issue'

Reason for proposal: This proposal is brought prior to any dispute resolution in the hope of finally ending this pronunciation issue once and for all simply by putting in a clarification using only a handful of words in the article straight away. The bit dug way down in the 'versions' section should be chopped as it doesn't seem to work at present. Other issues: This article has more pressing issues to be sorted as evidenced by its recent failure at a GA re-assessment. Therefore the aim is to not stick to your guns and wiki-lawyer guidelines, but rather to compromise and come to a consensus which differs from the status quo. Current: Mac OS X (Template:PronEng) is a line of computer... Pros: (why it's better than the proposals below) Cons: (why it should be replaced/not as good as the proposals below) While it's short and to the point, the alternative below (proposal #1) adds just a few extra words and addresses the re-occurring issue. Comments: Proposals for revision: (feel free to add your own) 1) Mac OS X (pronounced /mæk oʊ ɛs tɛn/; incorrectly as /mæk oʊ ɛs ɛks/) is a line of computer... Pros: (why it's better than the current text) Short and to the point; resolves issue straight away; sourced. Cons: (why it's not better than the current text, or what it doesn't address) Comments: 2) The article should mention that the 'X' is in fact a Roman numeral 10, and no mention of pronunciation is necessary at all. Comments: Insert your own compromise or comments below: MFNickster: I don't think I've changed my mind since the last time this was discussed; the article should mention that the 'X' is in fact a Roman numeral 10, and no mention of pronunciation is necessary at all. MFNickster (talk) 14:25, 9 March 2009 (UTC) I could easily be swayed this way since the bloody pronunciation bit is what's causing this circular headache. This is rather similar to example 2 above from the Simple English Wikipedia's article on OS X which doesn't seem to have the constant pronunciation issue. Nja247 14:47, 9 March 2009 (UTC) Althepal: This again? Ok here's the deal: Apple made version 10 of their OS and simply used the X roman numeral rather than "10". I think the article should somewhere explain why there is an X, saying that it is for 10 and not just a cool name. That is why the pronunciation was there: Since there is common perception, the article states that it is pronounced "10". I don't know whether or not it's important to say how people do something wrong. Still, the fact of the matter is that the whole topic isn't really clear, which is what causes the confusion. If it's version 10, why is Leopard not Mac OS 16? At first, "OS X" was to replace "System 9", but now there is a big different between the "classic" versions and the "OS X" versions. If this is the case, why is it still called "10"? As you can see, the whole topic is confusing to me just like many people. I know it's officially "OS ten" but I always read it in my mind as "OS ex". So, here's my proposal: We don't tell people how to pronounce it, rather we explain in the article (possibly in the intro) that the X stands for 10 as it came after System 9. I'm not sure if my opinion will change, but that's my two cents so use it as you will. -Althepal (talk) 21:53, 9 March 2009 (UTC) @Althepal: Exactly this again. That's why it's time to sort it out. Essentially are you saying what MFNickster said above you? Nja247 22:44, 9 March 2009 (UTC) Yeah, pretty much. Why do we have to tell people how to say something? Just clarify what the X is for and be done with it. Althepal (talk) 18:09, 12 March 2009 (UTC) Warren: I've taken a stab at rewriting the bit of text about the version number. Some edits made a couple of months ago buried this information in that pictureless, sectionless morass of overlinked text that is the "Versions" section. (ugh, why!?) I moved the information to the top of the "Description" section instead, where it will be more easily found, and I've expanded on the whole roman numeral vs. normal number thing... comments, all? Warren -talk- 22:13, 9 March 2009 (UTC) @Warren: At least we're trying. But wouldn't it ensure success by having it in there straight away? I think with a little work and imagination the intro could be tweaked to sort it. As for the adjustment: it's a start as it's higher up, however there's little reason to have pronunciation discussed twice in this article. Any ambiguities with it should be handled at the same time and then just be done with it. I am completely behind MFNickster's idea, alternatively I fail to see the issue with proposal 1 (ie adding several words straight away and then delete the secondary mention altogether. @Everyone: After reading, what do you all think? Do you think the slight modification to the intro should be such a sticking point? Do you believe the topic needs discussion twice in the article? If not, where should it be? If not in the intro could you explain how to avoid the issue as this method has failed to work in the past (ie that's why we're talking about it over and over again)? Aren't you all tired of talking about this as there's more pressing issues to sort? Cheers and good night :) Nja247 22:44, 9 March 2009 (UTC) We'll get it sorted out, Nja247. My only concern -- and I'm going to keep repeating it, because it's a message that needs to get through to more editors -- is the the lead sentence is absolutely NOT where we stick in a whole pile of extra information that the odd editor here & there thinks needs to be at the beginning of the article. The sentence needs to read like... well... a sentence. It needs to invite people to read further. It needs to make sense the first time. It needs to be straightforward. It needs to define the topic. Any article that goes down the path of "Topic name (blah blah blah; more blah blah blah, oh, and even more blah blah blah) is a blah blah blah blah blah (what it is)" can only be described as an attempt at punishing the reader for daring to learn about a topic. Simple! Keep it simple! Everyone here has seen articles whose lead sentence is unreadable due to excessive parenthetical facts. Let's avoid that. With that said, if someone wants to add a few words later in the lead section, after we've established what the heck Mac OS X is, that's completely fine by me. No more than a few words, though -- like I've said, it's not that important compared to everything else we have to say about Mac OS X. Warren -talk- 22:59, 9 March 2009 (UTC) @Warren: I see what you mean here and I understand the points of lead, ie to establish what the subject matter is first. And yes we definitely need to get the pronunciation point dealt with as soon as possible in terms of its location in the article so that we're not talking about this month after month. Further I too want to keep it as simple as possible. That is why I think it'd be helpful to learn specifically why proposal #1 above would not suffice? It's essentially two extra words along with the incorrect pronunciation. It's simple, sourced, and it addresses the issue immediately. Alternatively if we just stick something into the lead at a later point that means extra wording about pronunciation which I think could be avoided as it's not exactly keeping it simple. To me, keeping it simple would be handling all this pronunciation mess in one go. Nja247 08:22, 10 March 2009 (UTC) ZooCrewMan: Nja247, I greatly appreciate your offer of help with this rather ridiculous argument. I never, in a million years, thought that simply mentioning that saying Mac OS Ecks is a common variation would draw out the kind of vehement opposition that it has. I also never thought that there would be the kind of douchebaggery that has been seen. (Maybe we should mention how the scots say windows). We're not talking about a simple "mispronunciation" as so many of you have tried to claim. A mispronunciation would be calling it "Mach OS X" or "Mec OS X." Many, many people say, Mac OS Ecks. Simply mentioning this is not one of the signs of the apocalypse. Nobody is trying to "stick in a whole pile of extra information." What we're trying to do, is, right after the correct way to say it, insert a VERY COMMON ALTERNATE. That's all!!! I vote to insert the reference. ZooCrewMan (talk) 03:01, 10 March 2009 (UTC) It's not exactly 'ridiculous', but rather something that needs a proper discussion which is what we're now doing. We're not voting on what's right or wrong, instead we're trying to work together to come to a compromise and agreement on how best to sort things. This issue of pronunciation has come up since its introduction into the article and what we're trying to do here is have a calm and useful discussion about changes to the article in order to make it better and to avoid this re-occurring issue. It's not helpful for you to make bad faith comments as you did above. Constructive comments are welcome and appreciated, however if you plan to act contrary then please do not bother as it only hurts any progress. We're all volunteers here and things will only work out if we all act in good faith towards one another and actually try to compromise. Name calling destroys that. Nja247 08:22, 10 March 2009 (UTC) I understand your frustration with my comments, and I'm sorry if I offended you. I am not sorry for saying what I said though. I believe that the sarcastic "Scottish people pronounce Windows windaes" was just as unconstructive. There comes a point in time when frustration with a situation warrants letting other people know exactly how frustrated you are. This, I believe, was one of those times. First off, let me assert once more that this disagreement IS NOT about pronunciation. I am getting sick and tired of people trying to call it that. A mispronunciation is a difference is saying the same word. The letter X and the number ten are two very different things. If I said "Apple" was "pronounced "Microsoft" what would you all think of me? That I simply mispronounced it? If you want to dispute my claim here, look up the word pronounce in a dictionary. You're splitting hairs. If you want to call it a 'misnomer' rather than a 'mispronunciation,' then fine, but in practical terms it's an argument over how it is said out loud, i.e. pronunciation. How you pronounce an 'X' depends on whether you think it's a letter or a Roman numeral - I doubt you could find any other example in English where a Roman number is pronounced as the corresponding English letters, except as a joke. MFNickster (talk) 04:07, 12 March 2009 (UTC) Secondly, I did a short search for "also commonly called" and found many, many, many, many examples or articles where a simple inclusion is not a problem: Eosinophil granulocyte, Braddock expedition, Guinea pig, Petaling Jaya, Ampersand, Ho-Chunk (I could keep going if you'd like) For all of you out there proclaiming the "Official" way of saying things, are you going to go out, and re-edit these articles because "Petaling Java" is the "official" name of the city, and not PJ? Or are you going to remove the reference to calling an ampersand an "and sign" because "that's not how you say it?" Thirdly, I fail to see how mentioning this, or any other common alternate way to say something or call a thing is a "Weasel Word." Lastly, Notability, as defined by the opening sentence in its own article, "refers to whether or not a topic merits its own article." Its own article. I again, vote for the inclusion, not exclusion, of this simple (what should be uncontroversial) phrase that consists of 6 words. ZooCrewMan (talk) 01:51, 11 March 2009 (UTC) Nimakha: I agree with ZooCrewMan that the /ɛks/ variant should at least be given mention equal to the /tɛn/ variant, on the grounds of notability. However, after reading Warren's comments, I realize that this needn't be in the introduction. I now support keeping the naming details in a later subsection. The only complaint I have concerning Warren's rewrite is that it prescribes rectitude. It isn't the job of an encyclopedia to tell people how they aught to be doing something. Rather, the distinction we should be making concerns what's official versus what's common. —Nima Khazaei (talk) 06:45, 10 March 2009 (UTC) Thus do you think that the approach offered by MFNickster (above) would be a good alternative? He said: "..the article should mention that the 'X' is in fact a Roman numeral 10, and no mention of pronunciation is necessary at all". Nja247 08:22, 10 March 2009 (UTC) Dravick: I disagree that it's notable enough to merit inclusion in the article (see: Wikipedia:Neutral_point_of_view#Undue_weight), but if it is to be included, it should be made clear that it's a non-standard pronunciation. Contrary to what ZooCrewMan says above, it is a mispronunciation. The name of the OS is "Mac OS Ten," as Apple has called it from the beginning. It seems to me that the only reason this keeps coming up is because people who mistakenly call it 'eks' are so defensive about it. MFNickster (talk) 14:07, 10 March 2009 (UTC) I agree with MFNickster. We've talked about it a bazillion times, the official pronounciation is "ten", and the fact that this pronounciation is mentioned in the article should be enough (most articles do not even have IPA string). I suggest we leave it as it was, which is, mentioned somewhere in article, but certainly not at the top. I also suggest people should just live with it, even if they decide to pronounce it differently. I personally say Ooo-bon-too instead of Ooo-boon-too, yet I don't go cry about it in the Ubuntu article. Dravick (talk) 16:13, 10 March 2009 (UTC) @Dravick: Leaving it as is is no good due to the fact that every single archive including this page has had someone complain about this issue since its inclusion in the article. It has got to be properly addressed as the status quo has failed. I still haven't received an answer as to why the addition of two words and a reference into the intro is unacceptable. My view is there's no glaring issue with notability when considered as a whole and regardless that guideline should never be used to defend exclusion and continue this mess, ie harm Wikipedia as demonstrated by the recent failure at GA re-assessment. We shouldn't be wasting time on this and thus a compromise needs to happen. Additionally I think what MFNickster said has merit, ie scrapping the whole bit about pronunciation and simply mentioning it's a roman numeral and let the user sort it themselves. I hope contributors can comment on proposals for revision and compromise versus continuing this circular battle as it hasn't solved anything for well over the two years this has been going on. Nja247 04:59, 11 March 2009 (UTC) The GA reassessment failed because basically I was the one who was supposed to take time to address every issue, but I had too much work in real life to spend any time here. As for the current issue, I agree with Warren's suggestion just below. Dravick (talk) 17:52, 11 March 2009 (UTC) Yes, I had damn assessments and wished to spend more time helping. Once this is cleared up I'll look over the GA notes and do my best at tackling issues and then we can re-submit for review. Regardless the fact remains that energy will be better used not talking about this every month or so. Nja247 07:38, 12 March 2009 (UTC) Dravick (and others, of course), how do you feel about having something really short in the lead that clarifies that the X means the roman numeral "ten", but not explicitly address the pronunciation issue? We might also have to say that it replaces Mac OS 9, but by doing this, the progression from 9 to 10 can be inferred by the reader without belabouring the point. Warren -talk- 03:58, 11 March 2009 (UTC) Warren, could you, at your convenience, provide an example of how this revision might look keeping in mind our agreement to keep it simple and my hope for the point to be addressed as early as possible within the article. Nja247 07:38, 12 March 2009 (UTC) What about: Mac OS X (pronounced /mæk oʊ ɛs tɛn/; as the 'X' is a Roman numeral) is a line of computer... vs current, which is: Mac OS X (Template:PronEng) is a line of computer... Nja247 11:09, 12 March 2009 (UTC) I guess that could be it. In theory, IPA strings say it all, but of course I don't think most of us are familiar with the IPA (I sure am not). My main point was that the "ten/X" issue can be somewhere in the article, but it does not deserve to be in the first five words. On the other hand, I could see the fact that it is roman numeral "ten" being in the lead. Dravick (talk) 04:29, 11 March 2009 (UTC) Please, as a birthday present to me (I'm getting olddddddddd) consider my points directly above Warren's comment and get back to us. Cheers. Nja247 04:59, 11 March 2009 (UTC)

The pronounciation issue is silly. Most likely Mac intended it to be OS 10. They replaced the 10 with the roman numeral X, for aesthetic reassons, it looked cool. That led to OS X being pronouced as the letter X, not the number, as in Malcom X's last name. As WP is an encyclopedia not a grammar guide the question is whether or not the pronounciation of X as eks, not 10, is common enough to be worth noting. The question is not if it is correct, but if for cultural reasons it is worth noting, in the same manner that grammatically incorrect slang is worth noting. It might also be noted that the letter X and the roman numeral are the same character, and it was that way since roman times. X and 10 are the same character in the world we live in. If you call something OS X you are being purposely ambiguous. At around the same time OS X was introduced I think there was all that Malcom X stuff going on, with kids wearing hats with big Xs on them. I suspect that Mac was influenced by that also. So are there enough people saying OS eks to warrant a mention? Did Mac use the X instead of 10 because of all those Malcom X hats? I would sugggest a foot note to the pronounciation explaining that some actual people at the turn of the 21st century interpretted the X as eks. Geo8rge (talk) 20:24, 15 March 2009 (UTC)

Moving forward with "roman numeral" in the lead

Okay, after brainstorming for a couple of days, I've taken a whack at updating the lead section to incorporate the ideas we've built up.

Mac OS X (pronounced /mæk oʊ ɛs tɛn/, as the 'X' is a Roman numeral) is a line of computer operating systems developed, marketed, and sold by Apple Inc., and since 2002 has been included with all new Macintosh computer systems. It is the successor to Mac OS 9, the final release of the "classic" Mac OS, which had been Apple's primary operating system since 1984. 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, 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.

I tend to approach lead-writing by putting two "facts" into each sentence, like this:

1. It's an operating system / Apple made it.
2. It replaces Mac OS 9 and Mac OS more generally / Its predecessor was around since the mid-1980s.
3. The X means 10 / The core is Unix-based and was bought from NeXT.
4. Leopard is the most recent version / It is certified UNIX 03.

When using this approach, you have to be concise with each fact, and every sentence is high-value and informative. Even if a person doesn't read any further than the lead, you want them to go away with some of the biggest points, and make them feel like they've learned something.

Anyways, comments welcome... Warren -talk- 20:28, 12 March 2009 (UTC)

Well I've changed to what I think would address the issue best (directly above, not the article itself as there's no agreement yet). The reason for my change is the first thing seen is pronunciation and then you're forced to read on to find the info on Roman numerals which is aimed at avoiding constant discussions by the reading public who are unlikely to be so meticulous. I still think we could make the point straight away without hurting the fantastic approach you use for leads. We agreed to keep it simple, and I think we can be even more brief (see my revision). If the point isn't made sooner then I don't think we've accomplished much of a compromise.

Overall I agree with MFNickster and Althepal in saying scrap pronunciation altogether, ie tell readers it's a Roman numeral and let them sort it out. However if we can compromise and make the Roman numeral point along with the pronunciation, then fantastic as everyone should be happy and hopefully this is done with forever. If not I think we should consider the other proposal (remove pronunciation) as it would seem to have consensus and it seems to work for Simple English Wikipedia. Nja²⁴⁷ 20:57, 12 March 2009 (UTC)

I don't think we should scrap the pronunciation guide. We're supposed to use it in Wikipedia articles when the pronunciation isn't obvious or is contentious. But, pronunciation guides are only supposed to say what the correct way of saying it is, not why. I don't get the reasoning for putting that extra detail into the first sentence... why isn't the second sentence good enough? We do this in the Windows 2000 (it was released in 2000) and Windows XP (it stands for "experience") articles, why not here as well? Can't we at least get describing what it is out of the way before we delve into reasonings as to why it's named what it is? Warren -talk- 21:11, 12 March 2009 (UTC)

Yes, but guidelines shouldn't be strictly applied when there's been such confusion. Every archive since its introduction into this article has contained queries on it. We'll put it to consensus on whether the current re-vision works, or if my alternative is preferred, or even scrap it. I think telling people the X is a Roman numeral acts as a good alternative and possibly more proper guide for them on pronunciation, which is why there's a good argument (and agreement by three of us) to be rid of it as is if need be. And I don't think adding seven words, one of which is an 'X', makes it a long parenthesis. Hell remove the parenthesis if need be. It's best for clarity to stick it all together, especially when it's seven (or six and a half) words. Nja²⁴⁷ 05:15, 13 March 2009 (UTC)

I preferred the first formulation of the proposition. I don't know about you guys, but I tend to skip over long parenthesis. Furthermore, it implements the idea of mentionning it in the lead in a natural way, without being the first thing mentioned in the article. Dravick (talk) 23:51, 12 March 2009 (UTC)

I think the parenthesis is kind of superfluous when there's a citation to a source immediately following. YMMV. MFNickster (talk) 13:24, 13 March 2009 (UTC)

In my opinion, writing "Mac OS X (pronounced /mæk oʊ ɛs tɛn/, as the 'X' is a Roman numeral)" is just too long of an intro. Leaving the "as the 'X' is a Roman numeral" part out would still get the point across. But I still think it'd be best to leave out everything about how it's pronounced and why from the first sentence, working it in a better way into the article. I see that right now there is a sentence in the intro that explains what the X means, so I think there is no need to keep anything about it in the lead sentence. It's just not important enough. Althepal (talk) 18:45, 13 March 2009 (UTC)

It may be alright I suppose so long as there's no more monthly complaints about it now. If there are then it should be removed completely, ie the pronunciation. Nja²⁴⁷ 06:58, 14 March 2009 (UTC)

Need to delete criticism sections from Description, redo/delete Description section

Need to delete imo inappropriate criticism sections from Description/redo Description section

Under the 1st section called "Description" it says:

" In 2003 and 2005, two Macworld editors expressed criticism of the permission scheme; Ted Landau called misconfigured permissions "the most common frustration" in Mac OS X,[19] while Rob Griffiths suggested that some users may even have to reset permissions every day, a process which can take up to 15 minutes.[20] More recently, another Macworld editor, Dan Frakes, called the procedure of repairing permissions vastly overused.[21] He argues that Mac OS X typically handles permissions properly without user interference, and resetting permissions should be tried only when problems emerge.[22]"

I don't think this belongs here. If you want to create a section for Criticism(or Criticism for the release it applies to) then fine but otherwise I think we should stick to the claimed features for the Description section if indeed the section is needed.

Secondly, under the section that starts "The most visible change was the Aqua theme." The description of Aqua is fine but I'd put Criticism of it in the Aqua section http://en.wikipedia.org/wiki/Aqua_(user_interface)

Looking at the "Description" section as a whole vs other typical Wikipedia OS articles on say WIndows XP or Debian seems to make a case for getting rid of it entirely. It's half-way between describing features and Criticism that doesn't apply to every OS release. If I were quickly skimming this page I'd be under the impression that the filesystem for OS X may have permission problems and the interface of OS X is controversial.

I would propose Deleting the section entirely and moving the few Descriptions of the OS features into possibly the Introductory section. If you take away the criticism paragraphs and the OS market size paragraph then there are not many actual description sentences left. Those left can be put in the Intro, History, Features, and the aforementioned Criticism section.

Thoughts? Mesostinky (talk) 20:53, 15 March 2009 (UTC)

Ahh! This was discussed in depth and dealt with a while ago. The permissions thing at least has both sides of the argument. I personally feel that the aqua thing is a little negative (just because you're able to find someone who didn't like the change doesn't mean that's the most predominant view on the matter), but whatever. I'm not getting involved in this again. Althepal (talk) 22:57, 15 March 2009 (UTC)

Criticism sections are discouraged. There used to be one, but we were required to incorporate it in the text. See WP:Criticism_sections and other links I might find when I have a little bit more time. Dravick (talk) 13:01, 16 March 2009 (UTC)

"Common" criticism section

The added text is this:

In comparison to Microsoft Windows, some critics point to the lack of upgrade pricing on Mac OS X; users of previous versions have to pay full price for a new version. This is in part a semantic argument, depending on whether a retail Mac OS X package is considered an "upgrade" or not. On one hand, it can only be used on a Mac, all of which were sold with some version of the Mac OS, so it is arguably an upgrade. On the other hand, no price distinction is made between upgrading version 9.0 or version 10.3 to version 10.4, suggesting that consumers are buying a full license in either case, or at least receiving no credit for intervening upgrades. Furthermore, customers who purchase a Macintosh between the time a new version of Mac OS X is announced and the time it starts shipping preinstalled on new machines have typically been given upgrades at a much smaller cost (9.95-19.95 USD).

The Open Group has criticized Apple for use of the term "Unix" in advertisements for Mac OS X as Apple has not had the OS officially certified, and their use of the term could constitute a violation of trademark. Apple claims that they use the term as a genericized trademark and that the cost of certification would make the OS prohibitively expensive, although The Open Group has stated that there is a 110,000 USD upper limit on the cost of certification for one company. Though Mac OS X is "Unix-based" and features a BSD Unix compatibility layer, it is not compliant with the Single UNIX Specification. The reason for Apple not seeking "official" Unix branding may simply be that compliance is not a near- or medium-term goal for Apple instead of the potentially misleading cost claim.

In my opinion, the second part is obviously false, and the first part is hardly "common" criticism. I wouldn't mind deleting it altogether again, but that might lead to another edit placing it back in yet again. Dravick (talk) 20:30, 26 March 2009 (UTC)

The first argument is flawed since Mac OS X can ONLY be used to upgrade an existing copy of Mac OS. And nowadays, who's upgrading from version 9? Either way, everyone should be happy since it costs far less than Windows. The fact that Microsoft has various pricing schemes doesn't mean it's bad for Apple not to.

The second argument is simply untrue. Aside from being based on UNIX all along from its FreeBSD foundation, Mac OS X v10.5 is officially UNIX.

For both arguments, they are not even targeted at the operating system itself (either pricing or branding) and are hardly significant enough to dedicate a section to in an encyclopedia article. The section should not be re-introduced. Althepal (talk) 23:23, 26 March 2009 (UTC)

Personally, I think that there should be a a page that does list some of Mac OS X's shortcoming, and possible criticisms (if any), because that makes the page much more objective to wikipedia users, which I think is a goal of this website. —Preceding unsigned comment added by Sysrqx (talk • contribs) 02:24, 27 March 2009 (UTC)

There already _is_ some criticisms of Mac OS X in the article (as of now, only those about "permissions" were retained, but there was some about the Dock, the Finder, and so on that were moved to their respective page). If you want to add some, find a reliable source, and quote it in the article. Also, one source is not enough to be "common". Dravick (talk) 01:06, 28 March 2009 (UTC)

I think it's worth mentioning that there's a criticism section for just about every Microsoft product. The wiki seems to have a whole lot of unfair heat towards Microsoft. The lack of a shortcomings section for Mac OSX is inconsistent. And Mac OSX most certainly has shortcomings. Belugaperson (Talk|Contribs) 01:30, 30 March 2009 (UTC)

How is it inconsistent to follow Wikipedia guidelines and lean towards in-text criticism? Althepal (talk) 03:56, 30 March 2009 (UTC)

it is inconsistent to lay out explicit criticisms of Windows and other systems in their main articles, and then to bury all Mac OS criticisms in secondary articles. also, there are extensive problems with Mac OS, such as: compatibility issues and enforcing proprietary standards, a whole variety of things you can't do (changing certain fonts, colors, window decors, visually distinguishing between tasks and dock icons etc..), lacking interactivity and gaming APIs, imposing objective-C and its widely criticized models on developers, being tied to proprietary hardware, apple's NDAs and restrictive licenses in all corners of the OSX ecosystem, apple's refusal to provide 64 bit carbon, widespread backlash against "look and feel" restrictiveness, lack of drivers for certain hardware, criticism about closing the darwin kernel "to prevent piracy," stability and security issues (yes, they exist and have been well documented), criticism related to repeatedly breaking old software where windows can still run many exe files and even drivers from 1995, some discussion of the many good and well documented reasons why osx server really isn't useful as a commercial server, etc.. 70.55.42.238 (talk) 21:39, 4 April 2009 (UTC)

The way it's been done on these articles is completely consistent with Wikipedia's manual of style. Nja²⁴⁷ 06:53, 5 April 2009 (UTC)

For an operating system that is "lacking interactivity and gaming APIs" it sure has a lot of games available for it. Here's an idea, instead of whining on the talk page, how about actually trying to contribute some good edits to the article. If all these alleged problems are "well documented" how about you add them to the article, with reliable sources. Please note I said "good edits", anything that is badly sourced, or badly written will be removed promptly. AlistairMcMillan (talk) 01:35, 6 April 2009 (UTC)

OS X is not 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, 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. 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)

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

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, though, use of the environment is not required, and it is hidden by default.[60]

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, 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. In its sixth and most recent version, Mac OS X v10.5, the BSD layer passes UNIX 03 certification while running on Intel processors, though, use of the environment is not required, and it is hidden by default.

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

Good article...

As you may know, the article recently failed a GA nomination by me. A problem was, I didn't plan really well, and after the nomination I did not have that much time to dedicate to wikipedia. Mainly, the suggestions of the reviewer were really helpful, but concerning the part where he wanted to add a lot of comparisons with windows, I disagreed. I don't think that the article needs any mention of windows.

Now, if we look at the reasons the article was delisted in the first place here, I'm pretty sure all of those problems are resolved. The article didn't meet the expectations of the new reviewer, but it is still my opinion that the article is good enough to be GA.

So I don't really know what to do now. I'm pretty sure we could have been "luckier" and gotten a reviewer that liked it as it is, but I don't feel like renominating it so soon is the way to go. I would like to know what you guys think. Dravick (talk) 03:20, 16 April 2009 (UTC)

I agree that the suggestion about Windows isn't very productive and should not have meant the article to fail on that alone. The other issues seem covered and we should re-nominate for review. I'll work with you to try to get it passed, as will most of the regulars I'm sure. Nja²⁴⁷ 20:02, 16 April 2009 (UTC)