Talk:macOS/Archive 15

Archive 10

←

Archive 13

Archive 14

Archive 15

Archive 16

As to the table about Mac OS X 10.4 and 10.5

The very first 64-bit computing support was introduced with Mac OS X 10.4 for non-graphical console applications, and also in Intel documentations, EM64T was also supported in this version. The very first and last version of Mac OS X supporting 64-bit Graphical Application and 64-bit PowerPC Processor is Mac OS X 10.5. It is the only version exposed all the potential power of PowerMac G5. So these both versions need 64-bit processors to execute 64-bit applications. Then I made the correction to the table below. — Preceding unsigned comment added by 218.27.76.83 (talk • contribs) 17:22, 25 October 2015‎

The table needs to have columns whose interpretation is a bit more obvious - and whose contents are a bit more useful.

Possible columns:

• Processor architectures supported for user-mode code - this would combine PPC/Intel and 32/64-bit, e.g. the early ones would be 32-bit PPC only, Tiger would list 32-bit and 64-bit PPC and 32-bit and 64-bit Intel but with a note indicating that only non-GUI 64-bit programs are supported, Leopard would list those four without the note, Snow Leopard would list 32-bit PPC with a note indicate that it requires Rosetta and would list both 32-bit and 64-bit Intel, all subsequent versions would list only 32-bit and 64-bit Intel.

• Processor architectures supported for the kernel - this would be similar, with the early ones being 32-bit PPC only, Tiger and Leopard being 32-bit PPC and Intel, Snow Leopard being 32-bit and 64-bit Intel, and Lion and beyond only listing 64-bit Intel. That column also indicates what hardware is supported.

I suppose one could split Tiger into the pre-10.4.4 PPC-only version, the versions that supported PPC and 32-bit Intel, and the versions that also supported 64-bit Intel (I forget whether 10.4.0 supported 64-bit PPC or whether that was introduced later, possibly at the same time as 64-bit Intel, but I do remember 64-bit Intel support not being available in the first version supporting Intel). Guy Harris (talk) 01:35, 26 October 2015 (UTC)

I've eventually re-arranged the table shown below. The coloured units would help readers figure out the transitional products, but there is something I should mention below,

• PowerPC is a 32-bit stripped version of 64-bit POWER architecture, which also eventually evolved into PowerPC architecture, so PPC32 and PPC64 is the same architecture but different versions. Mac OS X 10.3 utilises the PPC64 feature to address physical memory above 4GB within kernel only, while Mac OS X 10.4 even further provides 64-bit computing support for non-graphical applications. They both had the trend to transit from 32-bit to 64-bit. But eventually for reasons, this failure transition were replaced by another transition from IA-32 to Intel 64. So I do not change the colour of unit which content is PPC32, PPC64.
• It is considered that Intel 64 is the superset of IA-32, but as to Mac OS X 10.7, it still retains the 32-bit hybrid kernel, mostly running under IA-32 legacy mode. So I change the colour of unit, which content is IA-32, Intel 64. Since OS X 10.8, the kernel is running purely under 64-bit mode, so there is no more situation for kernel and applications running under IA-32 legacy mode. Intel 64 is the ideal word to state this situation.
• Few documents detail the information on the 64-bit architecture of Intel processor and Mac OS X 10.4.x, so I leave it to the pure 32-bit O/S alone, waiting for some time later to make revision.
• Last but not least, I should have to say that the column of the original table should not be changed. Because the Processor Support, Processor Architecture and Kernel Mode reflect three most important factors of Apple's transition from AIM alliance's PowerPC to Intel x86. And what's more, in the OS X products, kernel-land and user-land codes are not that clear as traditional O/S. The Pink coloured Column Processor Architecture also provide information on the architectures sealed into universal binaries of Mac OS X. As a side, Mac OS X 10.4.1 is the first product support IA-32 architecture, only provided for developers. About ten years ago, I remembered, it was rumored that those special developers would obtain Pentium D based PowerMac-like machine to develop their software for then-future Intel Mac.

--- IP user who edited the following table — Preceding unsigned comment added by 218.27.76.83 (talk) 09:45, 26 October 2015 (UTC)

"PowerPC is a 32-bit stripped version of 64-bit POWER architecture, which also eventually evolved into PowerPC architecture, so PPC32 and PPC64 is the same architecture but different versions." The original POWER (Peformance Optimized With Enhanced RISC - Yet Another Lame Backronym) instruction set architecture was 32-bit; see IBM RISC System/6000 processor architecture (behind a paywall, alas), which speaks of the fixed-point unit as having 32-bit registers. PowerPC took that, added 64-bit capabilities, removed some instructions, added some instructions, and changed the specifications of some instructions; see Appendix E of PowerPC User Instruction Set Architecture Book I Version 2.02.

PPC v2.02 also says that

Processors provide two execution environments, 32-bit and 64-bit. In both of these environments (modes), instructions that set a 64-bit register affect all 64 bits, and the value placed into the register is independent of mode.

According to [http://www.iman1.jo/iman1/images/IMAN1-User-Site-Files/Architecure/PPC_Vers202_Book3_public.pdf PowerPC Operating Environment Architecture Book III

Version 2.02], section 2.2.3 "Machine State Register", the high-order bit of the Machine State Register controls whether the processor is in 32-bit mode or 64-bit mode.

So PPC32 is what you have when that bit is clear, and PPC64 is what you have when that bit is set. And, yes, the processor behaves differently, in some respects, in 32-bit mode and in 64-bit mode. (And there are processors that don't support PPC64, just PPC32.) There are fewer differences between PPC32 and PPC64 than there are between IA-32 and x86-64, but there are differences, so I don't see a reason to treat PPC32/PPC64 differently from IA-32/x86-64 in the table.

"while Mac OS X 10.4 even further provides 64-bit computing support for non-graphical applications. They both had the trend to transit from 32-bit to 64-bit. But eventually for reasons, this failure transition were replaced by another transition from IA-32 to Intel 64." I'm not sure what you mean by "failure transition", but in 10.5 full support was added for 64-bit user mode, both for PPC and x86, so the transition didn't fail to make 64-bit GUI applications possible for PPC. What was replaced wasn't the transition, what was replaced was that PPC was replaced by x86.

"It is considered that Intel 64 is the superset of IA-32, but as to Mac OS X 10.7, it still retains the 32-bit hybrid kernel, mostly running under IA-32 legacy mode." There's no "but" involved there; yes, in 10.5, and on some systems in 10.6 and 10.7, the kernel continued to run 32-bit (to make kernel data structures containing pointers smaller, and to allow 32-bit-only kexts to continue to run), but 64-bit user-mode code was fully supported. Except in cases where the kernel wasn't doing the work it needed to do to properly support all four combinations of kernel bit-width and userland bit-width (10.5 didn't properly handle BPF filters from 64-bit user-mode code, and 10.6 didn't properly handle BPF timeouts from 64-bit user-mode code), user-mode code didn't need to be aware of the bit-width of the kernel.

"Since OS X 10.8, the kernel is running purely under 64-bit mode, so there is no more situation for kernel and applications running under IA-32 legacy mode." In 10.8 and later, the kernel runs only in 64-bit mode, but applications can still run in IA-32 mode:

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.10.5
BuildVersion:   14F27
$ xcodebuild -version
Xcode 7.0.1
Build version 7A1001
$ cat foo.c
#include <stdio.h>

int
main(void)
{
        printf("Pointer size is %zu bits\n", 8*sizeof(char *));
        return 0;
}
$ gcc -arch i386 foo.c
$ ./a.out
Pointer size is 32 bits
$ gcc foo.c
$ ./a.out
Pointer size is 64 bits

"Last but not least, I should have to say that the column of the original table should not be changed. Because the Processor Support, Processor Architecture and Kernel Mode reflect three most important factors of Apple's transition from AIM alliance's PowerPC to Intel x86." There are three transitions, not one. There's the transition from supporting only 32-bit user-mode code to supporting 32-bit and 64-bit user-mode code (with an intermediate step, in 10.4, to providing a 64-bit libSystem but not other libraries), there's the transition from using PPC processors to using x86 processors (and, for a while, continuing to support PPC-based Mac with new versions of OS X, as well as continuing to support PPC applications on x86 with Rosetta), and there's the transition from only 32-bit kernels to supporting 64-bit kernels (first with support for both, and then without 32-bit kernel support).

So, for a given version of OS X, there's:

• Which types of instruction set (PowerPC, x86, or both) can it run on - 10.0 through 10.5 run on PPC, 10.4 and up run on x86;
• Which types of instruction set (PowerPC, x86, or both) can it support for application code - 10.0 through 10.6 support PPC, 10.4 and up support x86;
• Which bit-widths (32-bit, 64-bit, or both) can it run on - 10.0 through 10.3 run on 32-bit processors, 10.4 and up run on 64-bit processors, 10.8 and later run only on 64-bit processors;
• Which bit-widths (32-bit only or 32-bit and 64-bit) can it support for application code - 10.0 through 10.3 support 32-bit only, 10.4 also supports 64-bit command-line code, 10.5 and up support both 32-bit and 64-bit;

so the question is how to represent all four of those.

"About ten years ago, I remembered, it was rumored that those special developers would obtain Pentium D based PowerMac-like machine to develop their software for then-future Intel Mac." Those were called the "Developer Transition Kit". https://www.apple.com/pr/library/2005/06/06Apple-to-Use-Intel-Microprocessors-Beginning-in-2006.html Not a rumor]. Pentium D-based, in a PowerMac-style case. Guy Harris (talk) 19:56, 27 October 2015 (UTC)

OK, I change the colour of the unit which content is PPC32, PPC64, they both are transitional products. As to Mac OS X 10.7, the codes have also the chance to run under IA-32 legacy mode found on Intel 64 and IA-32 processors; since OS X 10.8, all the codes (32-bit and 64-bit) have only chance to run under IA-32e mode found on Intel 64 processors. So Mac OS X 10.7 is the last stop for this very transition. Transitional product does really mean that it is on the half way, not fully prepared for migration, maybe for some system routines, maybe for some standards. Unfortunately, Apple never realises the fully support for PPC64 architecture, even on Mac OS X 10.5, not all the system routines had been fully migrated to PPC64. When Mac OS X 10.5 was about official releasing, in mid-2007, there were seldom PowerPC based products on sale in Apple Shops. So the support for PPC32 and PPC64 had already become legacy for Mac OS X 10.5, no new Apple hardware would benefit from PPC based codes. XNU is a product heavily based on Mach kernel. Parts of traditional UNIX kernel in Mach would find convenient ways to be implemented in user-space, and maybe many versions would also be provided and configured onto the same O/S. Running 64-bit applications on the mixed 32-bit kernel of Mac OS X might be similar with it in running some IA-32 applications on Windows 3.x through Win32s API. But the real situation might be even complicated and irrelevant. From Mac OS X 10.3 to Mac OS X 10.7, all of them are on the way of computing transition from 32-bit (PPC32, IA-32) eventually to real 64-bit (Intel 64, most 32-bit IA-32 programmes are also supported within compatibility mode of Intel 64). The transitions of chip products and manufactures shocked the entire IT world, but are meaningless to the end-users.

--IP User who edited the following table — Preceding unsigned comment added by 119.51.184.70 (talk • contribs) 23:06, 27 October 2015‎

"OK, I change the colour of the unit which content is PPC32, PPC64, they both are transitional products" PPC wasn't a "transitional product"; it's not as if Apple intended to go to x86 from the beginning. They did x86 builds, to make sure the code continued to be able to run on x86 if they chose to switch to it, but that's not an indication that they intended to switch.

"As to Mac OS X 10.7, the codes have also the chance to run under IA-32 legacy mode found on Intel 64 and IA-32 processors; since OS X 10.8, all the codes (32-bit and 64-bit) have only chance to run under IA-32e mode found on Intel 64 processors. So Mac OS X 10.7 is the last stop for this very transition.". I don't remember the details from the talk given inside Apple on the 32-bit kernel/64-bit userland hackery, so I don't remember whether the 32-bit kernel ran in legacy mode or in long mode and compatibility submode; I suppose I could go dig through the XNU source to see which it was. If the former, 32-bit user-mode code might have run in legacy mode as well; if the latter, it probably ran in long mode and compatibility submode. Obviously 64-bit user-mode code runs in long mode and 64-bit submode. However, 32-bit code doesn't care whether it's running in legacy mode or long mode and compatibility submode; that's what "compatibility" means. So there's nothing interesting, from the point of view of 32-bit user-mode code, about the transition between 32-bit and 64-bit kernels. There's nothing interesting from the point of view of 64-bit user-mode code, either, as it runs in long mode and 64-bit submode on both kernels.

"Transitional product does really mean that it is on the half way, not fully prepared for migration, maybe for some system routines, maybe for some standards." Then the only "transitional" product was 10.4, which had limited support for 64-bit user-mode code.

"Unfortunately, Apple never realises the fully support for PPC64 architecture, even on Mac OS X 10.5, not all the system routines had been fully migrated to PPC64." Really? Which ones hadn't been migrated? They'd have to be assembler-language routines, or routines inside a platform-specific #ifdef, as C/C++/Objective-C-language routines would be 64-bit on both x86 and PPC. I doubt that claim is true.

"XNU is a product heavily based on Mach kernel. Parts of traditional UNIX kernel in Mach would find convenient ways to be implemented in user-space,, and maybe many versions would also be provided and configured onto the same O/S" Yes, in theory, that could be done. However, Apple never actually did that; that's why XNU is called a "hybrid kernel" - there's very little about it that's microkernelish.

"Running 64-bit applications on the mixed 32-bit kernel of Mac OS X might be similar with it in running some IA-32 applications on Windows 3.x through Win32s API." No, not similar. In user mode, the libraries were compiled "fat", containing PPC32, PPC64, IA-32, and x86-64 code. If the library makes a system call trap, the processor switches to 32-bit mode if it's a 32-bit kernel and 64-bit library or to 64-bit mode if it's a 64-bit kernel and 32-bit library as part of the system call trap process. The kernel code, when fetching stuff from userland or copying stuff to userland, checks whether the user-mode code is 32-bit or 64-bit, and translates between the userland format of the data structures and the format used in the kernel.

"From Mac OS X 10.3 to Mac OS X 10.7, all of them are on the way of computing transition from 32-bit (PPC32, IA-32) eventually to real 64-bit (Intel 64, most 32-bit IA-32 programmes are also supported within compatibility mode of Intel 64)." No, there were three transitions, one from PPC to x86, one from 32-bit-only to 32-bit-and-64-bit application and library support, and one from 32-bit kernels to 64-bit kernels. Guy Harris (talk) 21:08, 28 October 2015 (UTC)

I could go dig through the XNU source to see which it was

Excellent! But I am afraid that those critical codes might not be disclosed for open source. Anyway I wish that would help to improve the following table.

--IP User who edited the following table — Preceding unsigned comment added by 119.51.184.70 (talk • contribs) 16:11, 28 October 2015‎

Long mode and compatibility submode. See, for example, L_enter_lohandler2 in the 10.5.8 x86 idt64.s, which is for x86-64 machines (idt.s is for IA-32 machines). So it looks as if x86-64 machines with a 32-bit kernel run most of the kernel, and 32-bit user-mode code, in long mode and compatibility submode, and run 64-bit user-mode code in long mode and 64-bit submode. Guy Harris (talk) 00:02, 29 October 2015 (UTC)

Well, this is a good presumption. In this situation, it provides two complete suites of 32-bit kernel routines, one, purely 32-bit codes, running under legacy IA-32 mode for IA-32 processors; the other, mixed 32-bit codes, running under 64-bit Mode and Compatibility Mode for Intel 64 processors. For the latter, all the 32-bit kernel extensions and device drivers are running within Compatibility Mode too. This could be an efficient method, but problems arise. 32-bit codes in the Compatibility Mode does not have the privileges to finish jobs such as arrangement for paging, then those jobs must be mixed with 64-bit codes: first those paging algorithms are implemented with 32-bit codes, and then 64-bit codes assigns the products generated from 32-bit codes through paging unit; or everything is done using 64-bit codes. For the 32-bit interrupt handlers, 64-bit interrupt routines would trace back to the 32-bit routines in Compatibility Mode.

So there is another presumption: the kernel just provides only one complete suite of kernel routines, but some of which have two versions. In this presumption, 64-bit computing is treated like an extension, and all the kernel extensions and device drivers are running under legacy IA-32 mode for both IA-32 and Intel 64 processors. Only when 64-bit application is about to executing, the application loader creates a temporary 64-bit operating environment, prepares all the necessary things for it to run with 32-bit codes. The 64-bit interrupt handler part is the necessary component prepared for each interrupt from hardware and software, and traps the processor back to its legacy IA-32 mode, where the 32-bit processing routines do the real jobs. This is not likely an efficient method from the viewpoint of long journey transition of operating modes, but a bit more possible than the first presumption. And what's more, when Mac OS X 10.5 was about debuting, there were still many Macintosh computers based on pure 32-bit Intel processors, few applications were even Intel-bitlised, Office:mac 2004 was then the only productivity software running within the environment provided by Rosette Emulator.

--IP user who edited the following table — Preceding unsigned comment added by 175.17.63.241 (talk • contribs) 18:26, 28 October 2015‎

"In this situation, it provides two complete suites of 32-bit kernel routines, one, purely 32-bit codes, running under legacy IA-32 mode for IA-32 processors; the other, mixed 32-bit codes, running under 64-bit Mode and Compatibility Mode for Intel 64 processors." No, that's not what Apple did, so there is no point in discussing that any further.

"the kernel just provides only one complete suite of kernel routines, but some of which have two versions." That is what Apple did. The low-level code, and possibly the pmap code that handles the MMU, are examples of routines with two versions.

"all the kernel extensions and device drivers are running under legacy IA-32 mode for both IA-32 and Intel 64 processors." No, they run in legacy mode on IA-32 processors, and run in long mode and compatibility submode with x86-64 processors.

"Only when 64-bit application is about to executing, the application loader creates a temporary 64-bit operating environment, prepares all the necessary things for it to run with 32-bit codes." It's not temporary, it lives as long as the 64-bit process exists. The user-mode code runs with 64-bit code, obviously, as it's a 64-bit application.

And none of this is a "presumption", it's a description of what OS X actually does with a 32-bit kernel on x86-64. (On PowerPC, the kernel was 32-bit, with 32-bit pointers and 32-bit longs, but didn't have to go through quite as much pain to run 64-bit user-mode code.) Guy Harris (talk) 01:41, 29 October 2015 (UTC)

Too sure to be doubtful. As to the 32-bit kernel, 32-bit codes and compatibility mode, enough source is needed to prove its reality. This compatibility sub-mode of IA-32e mode is only actually utilised by 64-bit kernel for 32-bit applications (user-land).

--IP user who edited the following table 175.17.63.241 (talk) 02:03, 29 October 2015 (UTC)

That's right, I'm too sure to be doubtful about any of what I've said. (I was there when they did it, and saw the talk they gave inside Apple about it.) You want a source to prove what I said, here's a source, which is not only a source, it's the source (code to OS X). And what it says is that compatibility submode is used by the 32-bit OS X kernel as the mode in which it runs the vast majority of kernel code, as well as by both the 32-bit and 64-bit kernels to run 32-bit user-mode applications. Most OSes for x86 didn't do that, but OS X did, in order to preserve binary compatibility for kexts until the kext developers could make their kexts 32-bit/64-bit universal, and in order to reduce memory requirements for kernel data structures (32-bit pointers rather than 64-bit pointers). Guy Harris (talk) 03:47, 29 October 2015 (UTC)

Astonishing! That is to say there is nothing running under legacy mode of Intel 64 processor, even if the 32-bit kernel is running under IA-32e mode, especially Compatibility sub-mode. So I changed the colour and content of the corresponding unit. Or in other words, the 32-bit kernel within Mac OS X 10.7 is different from it in Mac OS X 10.5 and 10.6, it lacks the codebase residing on legacy mode.

The IP user who edited the following table 175.17.63.241 (talk) 06:04, 29 October 2015 (UTC)

"Astonishing!" Yes, the people who gave the talk at Apple said the Intel people were pretty astonished when they were told how the 32-bit kernel ran 64-bit user-mode code....

"That is to say there is nothing running under legacy mode of Intel 64 processor" Correct.

"Or in other words, the 32-bit kernel within Mac OS X 10.7 is different from it in Mac OS X 10.5 and 10.6, it lacks the codebase residing on legacy mode." The 32-bit x86 kernel in 10.4, the 32-bit x86 kernel in 10.5, the 32-bit kernel in 10.6 (there's no PPC kernel in 10.6), and the 32-bit kernel in 10.7 all run in long mode and compatibility submode on x86-64 processors. The 32-bit x86 kernel in 10.4, 10.5, and 10.6 run in legacy mode on IA-32 processors, because long mode isn't available; the 32-bit x86 kernel in 10.7 doesn't support IA-32 processors, and doesn't need to run in legacy mode (unless the machine has to pass through legacy mode during the startup process before going into long mode). It does, however, still have idt.s, so I'm not sure whether the support for IA-32 processors, and thus for running in legacy mode, was completely removed or whether that's still needed on x86-64 processors. Guy Harris (talk) 07:09, 29 October 2015 (UTC)

Well, if AMD had made another kind of AMD64 rather than today's version, it hybrids the PPC32 with 64-bit ISA of AMD64 without supporting IA-32 at all, it might challenge the transition from PowerPC towards Intel. If it were so, then Mac OS X would have transited from PPC64 to 64-bit ISA of x86-64 directly, without needing another kind of 32-bit computing. So I won't believe that was really astonishment towards Intel, rather than it, it is a surprise or gift from Apple to Intel. But that's all the past! This time I added information on the firmware support, that might help explain why 64-bit processor could not enable 64-bit kernel for some versions of Mac OS X, and the problem on the 3GB Barrier.

-- IP user who edited the following table 175.17.63.241 (talk) 00:57, 30 October 2015 (UTC)

OK, so:

• The row for Tiger should have two sub-rows, one for the PPC-only 10.4.0, with support only for Open Firmware, PowerPC, and PPC32/PPC64, with a note that PPC64 support is command-line only, and with a 32-bit kernel, and one for 10.4.1 and later, with support for both OpenFirmware and EFI32, both PowerPC and Intel, and PPC32/PPC64/IA-32/x86-64, and a 32-bit kernel, with a note that PPC64 support *and* x86-64 support is command-line only.

• The "Processor Architecture" column is not consistent. For Snow Leopard, it lists IA-32, Intel 64, and PPC32, which are the instruction set architectures it supports for application binaries, with PPC32 supported through Rosetta. For Lion, however, it lists only Intel 64, which is the instruction set architecture it supports for the processor it runs on; for application binaries, it supports both Intel 64 and IA-32. Please choose whether that column indicates the instruction sets for the processors on which the OS can run or the instruction sets for which it supports application binaries. Guy Harris (talk) 02:54, 30 October 2015 (UTC)

It is considered that Intel 64 is the superset of IA-32, so I use it to express the architecture, both 32-bit and 64-bit, supported by Mac OS X 10.7. I use IA-32 to denote the 32-bit only Intel processor and architecture, which Mac OS X 10.7 does not support. I also added information on Mac OS X Server 10.4.7 universal.

-- IP User who edited the following table 139.210.137.43 (talk) 04:32, 30 October 2015 (UTC)

You have not addressed the inconsistency in the "Processor Architecture" column.

If it lists the instruction set architectures that are supported for applications, then either Snow Leopard should list only Intel 64 and PPC32 if "Intel 64" includes IA-32, or all the ones after Snow Leopard should list IA-32 as well as Intel 64 as they support both 32-bit and 64-bit x86 applications.

If it lists the instruction set architectures on which the OS can actually run, then Snow Leopard should not list PPC32, as it will not run on PPC Macs, only Intel Macs. Guy Harris (talk) 08:38, 30 October 2015 (UTC)

In Intel Itanium document, it says, "IA-32 Architecture – The 32-bit and 16-bit Intel architecture as described in the Intel® 64 and IA-32 Architectures Software Developer’s Manual." So the architecture and Instruction Set sealed in compatibility sub-mode of IA-32e mode are not strictly equal to the IA-32. So I added two comments without changing the relate units of the following table.

"and with a 32-bit kernel, and one for 10.4.1 and later, with support for both OpenFirmware and EFI32, both PowerPC and Intel, and PPC32/PPC64/IA-32/x86-64, and a 32-bit kernel, with a note that PPC64 support *and* x86-64 support is command-line only.", I found that Mac OS X 10.4 Intel installation media seems almost another universal release. But I have no ideas if someone used it to install on PowerPC Mac. At least, I found no information about it on Apple website. So I would not change it this time. But through the 10.4.6, 10.4.7 and 10.4.8 delta updates for Intel, I found Intel 64 support information on 10.4.8, so I change the related table units.

-- IP user who edited the following table

You still have not addressed the inconsistency in the "Processor Architecture" column.

If it lists the instruction set architectures for which applications will work on the OS, then if you're going to treat "Intel 64" as including both 64-bit and 32-bit IA-32 code, then Leopard and Snow Leopard should just list "Intel 64", as they support both 64-bit and 32-bit x86 applications. Tiger, however, would have to list them separately, so that it can indicate that is supports GUI IA-32 applications but only command-line Intel 64 applications.

If it lists the instruction set architectures for processors on which the OS will run, then Snow Leopard should not list PPC32, as Snow Leopard only runs on Intel Macs, even though it can run PPC32 applications through Rosetta.

As for the Intel manual quote, all it means is that the "Intel® 64 and IA-32 Architectures Software Developer’s Manual" describes, as the title itself makes obvious, both the Intel 64 and IA-32 versions of the architecture; Intel 64 is a superset of IA-32, in that an Intel 64 processor supports all the processor modes IA-32 does (real, 16-bit protected, and 32-bit protected), and also supports long mode.

Long mode in compatibility sub-mode isn't 100% compatible with legacy mode 32-bit protected sub-mode; as section 3.1.1 "Intel® 64 Architecture" of volume 1 of the Intel® 64 and IA-32 Architectures Software Developer’s Manual says:

Legacy applications that run in Virtual 8086 mode or use hardware task management will not work in this mode.

As far as I know, few if any OS X apps used either of those capabilities, however, so they should all work on OS X on Intel 64 processors. Guy Harris (talk) 02:49, 31 October 2015 (UTC)

Well, Mac OS X or OS X is something different from UNIT-like O/S, it is not written for some a specific architecture, but for some a specific computer system. So the Processor Architectures mentioned here is mostly the touchable things, in other words, they should be supported by the system kernel and/or user-land routines. They might present on the real processor, or emulated by ISA emulator. So from this very viewpoint, the PPC64 on Mac OS X 10.3 is not touchable for userland applications. Even if application programmers could have writen some applications using the 64-bit GPRS of PPC64, but the kernel itself does only maintain the shrunk 32-bit values. It would incur problems when those processes swap in and out. And in fact, the situation of PPC64 in Mac OS X 10.3 is similar with 386 enhanced mode in Windows 3.1x. Windows 3.1x is designed for 80286 based system, but borrows some functions from 80386 processor to support even more physical memory than 16MB. Back to the situation of PPC64 and Mac OS X 10.3, the kernel just borrows some functions from PPC64 processor, rather than really support the PPC64 architecture. So I did not list it in the following table. As to the Mac OS X 10.4, not only the libSystem but also the kernel itself knows how to manipulate 64-bit codes, the situation changed. Early version of 10.4 Intel does not support Intel 64 at all, no matter IA-32 processor or Intel64 one are treated as the IA-32 one. So it support the real IA-32 architecture. After universal server edition released, both updates merged together, so Mac OS X 10.4 Intel had the 64-bit capabilities, EFI64, x86-64 version of libSystem and mach kernel itself happened to change. This time Intel 64 processor is running under compatibility mode mostly rather than treated as another IA-32 processor. So I list Intel 64 to that table unit. There are large differences between Mac OS X 10.6 and 10.7, and the most obvious one is that in the latter one, there is no support of 32-bit IA-32 processor. So there is no processor in Mac OS X 10.7 treated as IA-32 processor, so that architecture could really be taken over by Intel 64. Or in other words, the backward-support could clearly describe that how touchable it is for the support of applications written for IA-32 architecture.

-- IP user who edited the following table

What on earth is a "UNIT-like OS"? I have never heard that term.

If you mean "Unix-like OS", then most Unix-like systems, these days, are not written for some specific architecture - Solaris runs on SPARC and x86, HP-UX runs on PA-RISC and IA-64, Linux runs on a lot of different instruction set architectures, and most *BSDs run on at least two instruction set architectures, so that's clearly not what you meant.

"So the Processor Architectures mentioned here is mostly the touchable things, in other words, they should be supported by the system kernel and/or user-land routines. They might present on the real processor, or emulated by ISA emulator." Then it's the instruction set architectures for which applications will work on the OS. In that case, if you're going to draw a distinction between the IA-32 instruction set architecture and the instruction set architecture in compatibility sub-mode of long mode (the differences being the lack of virtual 8086 mode and support for hardware task management, as per the Intel manual), it would be far clearer if "Intel 64" were stated as "Intel 64 long mode and compatibility sub-mode", although, from a practical point of view, for most if not all OS X applications, there is no difference between IA-32 in 32-bit protected sub-mode and Intel 64 in long mode and compatibility sub-mode.

"There are large differences between Mac OS X 10.6 and 10.7, and the most obvious one is that in the latter one, there is no support of 32-bit IA-32 processor." That "large difference" mainly consists of the removal of support for IA-32 processors from the kernel. However..

"Or in other words, the backward-support could clearly describe that how touchable it is for the support of applications written for IA-32 architecture." ...there is absolutely no difference between 10.6 and 10.7 in support for applications built for IA-32 architecture, other than support for virtual 8086 mode (which I'm not sure OS X supports at all) and hardware task management (which OS X might also not support). Guy Harris (talk) 07:15, 31 October 2015 (UTC)

I typed something wrong, it is UNIX-like, not UNIT-like. Well, OK. As to Intel 64 processor, the legacy IA-32 architecture are not compatible with 64-bit architecture. But the 64-bit architecture of Intel 64 processor, Intel 64 architecture, is backward compatible with most programmes written for IA-32 architecture. This is difference between the relationship of PPC32 and PPC64. PPC32 is the scale-down version of PPC64, so PPC32 is upward compatible with PPC64, and PPC64 is backward-compatible with PPC32.

--IP user who edited the following table

"the legacy IA-32 architecture are not compatible with 64-bit architecture" only in the senses that 1) code that runs in long mode, 64-bit submode won't run on an IA-32 processor and 2) code that uses virtual 8086 mode or hardware task management won't run in long mode, compatibility submode. Code that runs on an IA-32 processor will run on an Intel 64 processor running in legacy mode, and almost all user-mode code that runs on an IA-32 processor (and even, as per the 32-bit OS X kernel, even most kernel-mode code that runs on an IA-32 processor, if the right stuff is done in the lower layers of the kernel) will run on an Intel 64 processor running in long mode, compatibility submode. That's rather a lot of compatibility, and that compatibility is probably a reason why x86-64 succeeded in the marketplace.

"PPC32 is upward compatible with PPC64" in the sense that user-mode PPC32 code will work on a PPC64 processor (if the OS cooperates, but that's true of any 32-bit architecture extended to 64 bits). "PPC64 is backward-compatible with PPC32" in the sense that user-mode PPC32 code will work on a PPC64 processor (if the OS cooperates, but that's true of any 32-bit architecture extended to 64 bits). Obviously, PPC64 code will not run on a PPC32-only processor.

And before you talk about otherwise 32-bit code on a PPC64 processor being able to use all 64 bits of the GPRs, please read about the x32 ABI.

So what is the big difference here between x86 and PPC in that regard? Guy Harris (talk) 09:03, 31 October 2015 (UTC)

Compatibility Mode, where the 32-bit kernel and 32-bit applications work, is part of Intel 64 architecture, but not part of IA-32. So Intel 64 is exactly the Processor Architecture of Mac OS X 10.7. Saying Intel 64 architecture implies most programmes written for IA-32 architecture are compatible with this architecture. In Mac OS X 10.6, the 32-bit kernel and 32-bit applications work under protected mode of IA-32 architecture for 32-bit Intel processor; the 32-bit kernel and 32/64-bit applications work under IA-32e mode of Intel 64 architecture for 64-bit Intel processor; the 32-bit PowerPC applications work under Rosetta emulator, which is part of Macintosh system. So for the Mac OS X 10.6, the Processor Architecture is IA-32, Intel 64 or PPC32. IA-32 and Intel 64 present on the real processors, while PPC32 present on the virtual processor (emulator). PPC32 is a scale-down version of PPC64, or in other words, PPC64 is scaled up from PPC32. But the compatibility mode (backward-compatible IA-32 architecture) is alongside with 64-bit mode (64-bit architecture). So in Mac OS X 10.3, the 64-bit PowerPC is used as a scaled-down version, the Processor Architecture is essentially PPC32; while in Mac OS X 10.7, Intel 64 is the best choice. That's the big difference.

Because the 32-bit kernel of Mac OS X 10.7 could run 64-bit applications, so the 32-bit applications has the potential possibilities to hybrid part of itself with 64-bit codes. Then this hybrid 32-bit applications could not run on IA-32 architecture. That is some better reason that I give to use Intel 64. I also added (32-bit, 64-bit) below it, and I wish this would help make it clear.

--IP user who edited the following table — Preceding unsigned comment added by 139.210.137.43 (talk) 13:03, 31 October 2015 (UTC)

Then, to be consistent, you should say "Intel 64 (32-bit, 64-bit)" for 10.5, and 10.6, as well as 10.7, to clarify that all of them support both 32-bit and 64-bit applications. For 10.4, you should say "Intel 64 (32-bit, 64-bit CLI only)" to clarify that it support all 32-bit applications, and supports only 64-bit CLI applications.

In addition, for 10.4, you should say "PPC32, PPC64 (CLI only)" to indicate that only 64-bit CLI applications are supported.

"Because the 32-bit kernel of Mac OS X 10.7 could run 64-bit applications" That's also true of the 32-bit kernel of 10.4, 10.5 and 10.6.

"so the 32-bit applications has the potential possibilities to hybrid part of itself with 64-bit codes" No, OS X doesn't support anything like x32, so you can't have a 32-bit application with some 64-bit code in it for Intel 64. That's true of 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, and 10.11. Guy Harris (talk) 15:05, 31 October 2015 (UTC)

That's right! If you think some a time is ok, you are welcome to represent the following table onto the main article. Any modification is also welcome to it. Thank you.

I've changed the table and added the relative information. As to the firmware, especially EFI. I have to say that EFI32 is not bootia32.efi, and EFI64 is not bootx64.efi. Later information on EFI specification might possibly to add into the table.

I've also added the information on Intel Rhapsody, that might be the important reason why Apple named their Mac OS X 10.7 as Mac OS X (for it still retains the 32-bit kernel), but removed the cap (Mac) from OS X 10.8 and later versions. Not only the NeXT, but also the Apple in mid 1990s developed a hybrid computer, dual systems. dual processors, dual architectures. That machine could also run Windows 95 alongside with Mac OS. Fantastic! From all those things, the transition to Intel was the expectation long-long before PowerPC970 was improper for mobile computing.

I did not want to make any change, but eventually I changed the information on Mac OS X 10.7. Even though the 32-bit kernel and 32-bit applications are backward supported within compatibility sub-mode of IA-32e. But just like PPC32 was emulated by Rosetta as part of Macintosh system, this IA-32 architecture, or i386 (output of uname -a within Mac OS X 10.7), is realised on a new architecture of a new processor, Intel 64. For keeping the consistency with the name Mac OS X, I think the change that I made is valuable. As to the OS X 10.8 and later versions, the Processor Architecture is exactly the Intel 64, but most programmes written for IA-32 architecture could also run on those new systems, so Intel 64 (32-bit, 64-bit) could make it clear.

--IP user who edited the following table 119.51.186.57 (talk) 02:59, 1 November 2015 (UTC)

"From all those things, the transition to Intel was the expectation long-long before PowerPC970 was improper for mobile computing." You're just guessing there. There's a difference between being prepared to switch to Intel if it became necessary (which Apple definitely were prepared to do with Mac OS X, as they did builds for PCs internally, to make sure the x86 support didn't suffer from bit-rot) and expecting to switch to Intel.

There is no difference between the x86 application support on 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, and 10.11 on Intel 64 processors. All of them support both 32-bit applications in compatibility mode and 64-bit applications in long mode. Therefore, all of them should say, in whatever column indicates what application instruction sets are supported, "Intel 64 (32-bit, 64-bit)".

"But just like PPC32 was emulated by Rosetta as part of Macintosh system, this IA-32 architecture, or i386 (output of uname -a within Mac OS X 10.7), is realised on a new architecture of a new processor, Intel 64." There's nothing "like" about them. PPC is emulated on IA-32 and Intel 64 with Rosetta software. 32-bit and x86 code is executed in hardware on Intel 64 processors. And if you're going to say "this IA-32 architecture, or i386 (output of uname -a within Mac OS X 10.7), is realised on a new architecture of a new processor, Intel 64.", then you should simply say "IA-32" and "Intel 64" in the column that indicates what application instruction sets are supported.

As for uname -a, that's just uname -mnrsv, as the man page says. uname -m prints "the machine hardware name", whatever that is supposed to mean; uname -p prints "the machine processor architecture name", whatever that is supposed to mean.

Mac OS X 10.7, when running on an Intel 64 machine, prints, for uname -m, "x86_64", and prints, for uname -p, "i386".

OS X 10.10 does the exact same thing, as do OS X 10.8, OS X 10.9, OS X 10.11. 10.6 prints "i386" for both. But don't read too much into any of that; you just get into trouble if you try to guess, based on how you think, what other people thought when they did something. Guy Harris (talk) 07:10, 1 November 2015 (UTC)

The IA-32 in sentence "most programmes written for IA-32 architecture could also run on those new systems." is different from it in "this IA-32 architecture, or i386 (output of uname -a within Mac OS X 10.7), is realised on a new architecture of a new processor, Intel 64." Because for the latter, developers of Mac OS X also made efforts to enable 32-bit kernel extensions and 32-bit device drivers work without problem, making the end-users operate as if they were really working on the IA-32 architecture. All those efforts, in other words, were put to realise the upward compatibilities from IA-32 to 64-bit architecture (Intel 64) and fill in the gaps between them from software programming standpoint. That is the astonishment you mentioned before. I denoted Intel 64 (32-bit, 64-bit) for Mac OS X 10.6 through OS X 10.11, but did not do it for Mac OS X 10.4 and 10.5. The reason is that both of Tiger and Leopard do not equip with a 64-bit kernel, but that realised IA-32 and 64-bit architecture are visible to the end users. As to Snow Leopard and later versions, 64-bit kernel is provided, so 64-bit and 32-bit applications both are supported under Intel 64 architecture.

As to the uname -a, ok, for system equipped with 32-bit only EFI firmware, or EFI32, the results of uname -pm is i386, i386, even if the processor is 64-bit and 64-bit applications are supported.

-- IP user who edited the following table 119.51.186.57 (talk) 08:26, 1 November 2015 (UTC)

In third table below, I've also added information on additional operating environments supplemented by Classic Environment and Boot Camp. Classic Environment provided two ways for backward compatibilities with applications written for Mac OS, hosted within Mac OS X, or a secondary O/S installed onto the same computer. While Boot Camp is widely considered to be a utility for creating storage space and providing drivers for Windows O/S. Even without Boot Camp, users could also install Windows onto an Intel Mac, making it as the only O/S. But Macintosh is not designed for completely open standard computing system. It does not set up some open standards on configurations for other computer manufacturers to clone their products. Mac OS X is the necessary and inseparable part of Macintosh. The Intel Mac provides the compatibilities to Microsoft Windows O/S, for the firmware, storage space, hardware support,..., and everything based on Intel core enable the implementation of compatibilities easier than ever before. But that is not to say that it is another PC from Apple, just Boot Camp is that window from Macintosh towards Windows O/S. So the support of Windows O/S is also part of Mac OS X system. I merged two environments into one column, and treated them both equally.

--IP User edited the following tables 218.27.80.215 (talk) 02:54, 5 November 2015 (UTC)

At this moment, the table in the main article is still problematic, and my suggestion and effort turn to be completely in vain. Es ist sehr schade, aber I am  Done from here.

-- IP User who edited the following tables 218.27.81.236 (talk) 05:47, 8 November 2015 (UTC)

Janagawen, your suggestions were bogus, which is why they were in vain. If you seriously think, for example, that the bit-width of the kernel is different from the bit-width of supported kexts, you are so ignorant of the OS X kernel that your changes made the table worse, not better. Guy Harris (talk) 09:19, 8 November 2015 (UTC)

Who is Janagawen? What is that? That takes non-sense. But please correct the codenames of Mac OS X Developer Preview and Public Beta. Besides that, Application support is a worse description, you might use kind to take place of it. Mac OS X 10.2 G5 release supports PowerPC G5 (PowerPC 970) processor, but you could treat it as another 32-bit PowerPC processor. Rhapsody Developer Release provided 80486 release first, and then for PowerPC. Those could be called bogus which you find time to debug in the future.

"bit-width of the kernel is different from the bit-width of supported kexts", sorry, I do not understand what you said. But on the first table shown below, take Mac OS X 10.2.8 G5 for example, it possesses a 32-bit kernel with supporting only 32-bit KEXT, but in order to support PowerPC G5, instructions of 64-bit architecture (PPC64) are necessary involved. As to Mac OS X 10.3, advanced features of PowerPC G5 is borrowed into its kernel, which in Mac OS X 10.4 is also further extended to support 64-bit processes depending on 64-bit version of libSystem. How can a 32-bit kernel support a 64-bit process above on it? Blind, like it in all those beautiful and innocent days when 32-bit applications running on 16-bit DOS? No, completely no. But the fact is that they are not virgins! They are just essentially 32-bit kernels, from the 32-bit standpoint, they are upward to support 64-bit computing. But the true story is just like that an experienced actress portrays an innocent young lady. OK, you could treat it a bogus. I have already said done from here, but I have to make those words.

-- IP user who edited the following tables Janagewen7 (talk) 00:20, 17 November 2015 (UTC)

Apps that didn't make it

Hello, one thing I'm considering adding a bit more on is mention of notable applications that didn't make the transition to OS X and ran on classic until the switch to Intel killed them off. My impression through reading old articles (I wasn't using Macs at this time) is that quite a few notable ones didn't make it, such as FrameMaker and PageMaker. Any others? Was thinking of adding a longer list to the Classic Environment article too. Blythwood (talk) 03:57, 30 November 2015 (UTC)

That seems very interesting, but would you please start a page on your sandbox before putting them onto the main article? We talk about Mac OS X (talk) 04:26, 30 November 2015 (UTC)

Verbosity

Hi guys. I was just thinking that the History and PowerPC-Intel transition sections are far too long, because they are just supposed to be summaries of main articles rather than serving to replace them. Blythwood just did a ton of really admirable work in citing the whole article, and I didn't know whether that's new content or whether it's come from the main history article. If the latter, then that content and more, should basically go back there. Also I was thinking that the whole list of versions should be collapsed in the ToC. Thank you very much because this is a really great article. — Smuckola(talk) 22:42, 8 December 2015 (UTC)

Yes fair enough, when I was adding material there I was starting to wonder how to handle having a concise version here and a longer version in the History of OS X article. Will think about this - happy to welcome others' input as long as any content felt to be too much here is being moved over to the history article. Blythwood (talk) 22:53, 8 December 2015 (UTC)

@Blythwood: Hey there. So was that basically all-new content? Is it not redundant to History of OS X? I'm just asking because I don't know. If so, the most important thing is that you got it together and published, since it's so high quality. I'd say that the sections I mentioned should be about a quarter of the length of what they presently are, because they have main articles. They should just be a brief casual overview (like the main articles' leads) for someone who really doesn't care very much or else they'd read the main article. This article has a lot of such sections, but still a lot of completely unique content. Thanks a lot. — Smuckola(talk) 17:05, 9 December 2015 (UTC)

@Smuckola: Yes, on balance it is a bit redundant. I felt I should something there to describe general trends, for example the fact that early OS X reviews criticised it for being slow. I see now it would make sense to pare it down and move content into the history article, maybe the bit from 'Apple rapidly developed...' onwards - feel free to do what you want to it. Perhaps skip from there to ... From 2012 onwards. Blythwood (talk) 14:29, 16 December 2015 (UTC)

Rosetta

"PowerPC (10.0–10.5.8; PowerPC applications still supported on x86 with Rosetta up to 10.7"

It was up to 10.6.8. — Preceding unsigned comment added by 76.75.93.92 (talk) 23:40, 17 December 2015 (UTC)

You were right, fixed, thanks. — Smuckola(talk) 01:11, 18 December 2015 (UTC)

Whether it's correct or not, people use "up to" in both the inclusive sense (where "up to 10.6.8" would be correct) and the non-inclusive sense (where "up to 10.7", as in "10.7 was the first release where it's not the case", would be correct) - it means "until" in the non-inclusive sense - so it wasn't incorrect. It was, however, ambiguous, so your rewrite, avoiding "up to" entirely, is the right way to say it. Guy Harris (talk) 01:25, 18 December 2015 (UTC)

When was the "Mac" dropped?

The lead section says "OSX" was "originally Mac OS X", yet I can't find a single reference in the article when the product name change occurred. Was it ever officially called "Mac OSX"? — Quicksilver^{T @} 21:59, 19 January 2016 (UTC)

Never "Mac OSX", with no space between the "OS" and "X", but it was officially called "Mac OS X", with a space between the "OS" and "X", from Mac OS X 10.0 through Mac OS X 10.6, as indicated by Apple's pages for the OS from 10.0 through 10.6. For 10.7, Apple used both names; for 10.8 and later, they called it OS X. Guy Harris (talk) 22:24, 19 January 2016 (UTC)

Semi-protected edit request on 15 February 2016

210.10.132.228 (talk) 05:45, 15 February 2016 (UTC)

The request is complete nonsense at multiple layers. Guy Harris (talk) 07:14, 15 February 2016 (UTC)

Predictable Sequence Numbers

Article claims predictable sequence numbers, but without proof. I see a "wireshark" screen cap, but wireshark will automatically "normalise" sequence numbers so they're offset-0, which is great for debugging, but it's not proof of the predictable numbers. In fact, I can see that the sequence number here is 0x7637f368, not "1". -- Ch'marr (talk) 23:18, 24 February 2016 (UTC)

Yes. If somebody wants to prove predictable sequence numbers using Wireshark, they either need to 1) turn off the "Relative sequence numbers" preference for TCP or 2) manually dissect the TCP header to get the sequence number directly from the packet, as you did. Only if the initial sequence number they get from that is predictable can they conclude that it uses predictable sequence numbers. Guy Harris (talk) 23:58, 24 February 2016 (UTC)

10.11.4 beta 5

Matrix9180 (talk) 05:07, 2 March 2016 (UTC) 10.11.4 beta 5 (15E56a) was released to testers on March 1, 2016.

And that's what the page says, although you might have to purge some Wikipedia server's cached copy to see it; from the "More" menu, select "Purge". (The information is in a template that's included by the page, and an edit to the template won't necessarily immediately show up on pages that include the template - a purge might be required.) Guy Harris (talk) 05:17, 2 March 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on OS X. Please take a moment to review my edit. You may add {{cbignore}} after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether, but should be used as a last resort. I made the following changes:

• Attempted to fix sourcing for http://blogs.adobe.com/jnack/2008/04/photoshop_lr_64.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 03:03, 31 March 2016 (UTC)

I found it! Guy Harris (talk) 06:16, 31 March 2016 (UTC)

Hardware <=> SheepShaver emulator

The SheepShaver emulator can run more than Mac OS 9 - it can run all versions of PPC Mac OS from OS 7.5.3 to 9.0.4 (using the "old world ROM") or OS 8.5 to 9.0.4 (using the "new world ROM"). It can run Classic Mac applications not just on Leopard, but as far as Yosemite, and - currently being tested - El Capitan. Likewise there are two other emulators overseen by the same people : Basilisk II (for System 6 through 7) and Mini vMac for earlier systems, both for 68k Macs. None of these is supported anymore but there is still an active community using them, and active user forums at http://www.emaculation.com/forum/index.php 79.69.18.101 (talk) 14:10, 7 April 2016 (UTC)

Semi-protected edit request on 13 April 2016

In the article, mention that the name is a pun (The OS is the tenth generation of Mac OS, and the name also mentioned that it is a *nix) 111.194.104.216 (talk) 13:09, 13 April 2016 (UTC)

 Not done Please be clear about what you want to be edited, if it needs to be sourced, add the link here. --QEDK (T ☕ C) 19:33, 14 April 2016 (UTC)

Change of article name

Today, Apple has announced that the name of OS X will be changed to "macOS." The title of the article should be changed accordingly.

107.185.212.78 (talk) 19:14, 13 June 2016 (UTC)

Currently, MacOS and thus macOS redirect to Mac OS. If we rename this page to "macOS" - as probably should be done - it would have to be done over the redirect, and would thus require an administrator's help. Guy Harris (talk) 19:16, 13 June 2016 (UTC)

Main Image is Terrible

The top / main headshot image is absolutely drab, and not commissioned by Apple as a good consumer or contributed image. Someone has changed the previous beautiful image to a drab one. Could be hackers.— Preceding unsigned comment added by 72.209.223.190 (talk • contribs) 08:29, 14 July 2015 (UTC)

Add hyperlink in text on request on 14 June 2016

In the sixth paragraph of general description, the "iOS" text should have a hyperlink to the iOS Wikipedia page for consistency as other platforms have the corresponding hyperlinks already. This can let readers quickly navigate to the iOS page for more information.

The sixth paragraph looks like below: During WWDC 2016, OS X was renamed to macOS to match the naming scheme of Apple's other platforms, tvOS, watchOS and iOS, with macOS Sierra...

Sam.cheng (talk) 17:16, 14 June 2016 (UTC)

 Done. Guy Harris (talk) 17:56, 14 June 2016 (UTC)

Requested move 13 June 2016

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: No consensus to move the article has been established within the RM time period and thus defaulting to not moved. (closed by non-admin page mover) — Music1201 ^talk 16:58, 20 June 2016 (UTC)

---

OS X → MacOS – Apple renamed the operating system from OS X to macOS today at WWDC 2016. —MRD2014 T C 20:38, 13 June 2016 (UTC)

• Oppose. Titles can't start with a lowercase letter. Georgia guy (talk) 20:54, 13 June 2016 (UTC)

I changed it: we can just use the lowercase magic word on the article. —MRD2014 T C 21:03, 13 June 2016 (UTC)

{{lowercasetitle}}

-- Meow 01:22, 14 June 2016 (UTC)

• Neutral now, support in September. Sceptre ^(talk) 21:13, 13 June 2016 (UTC)
• Support, although I wouldn't oppose waiting until it ships. Guy Harris (talk) 21:40, 13 June 2016 (UTC)
• Support, as Apple has described it as macOS everywhere in the Developer website. -- Meow 01:22, 14 June 2016 (UTC)
• Oppose for now: I think this is premature. The OS isn’t even released yet and Apple still mentions ‘macOS’ nowhere except on the feature page. Everywhere else it is still called OS X. I would wait until this name has settled a bit.–Totie (talk) 01:58, 14 June 2016 (UTC)
• Neutral for now: I agree with Sceptre and Guy Harris more or less. macOS Sierra doesn't launch until the fall; OS X El Capitan is currently the most recent released version of the operating system, so it makes sense to keep the current page name for the time being. —zziccardi (talk) 02:20, 14 June 2016 (UTC)
• Oppose for now. Seems too soon for a move, as Totie said. In a few months if it becomes more commonly used, I'll support. Anarchyte (work | talk) 04:20, 14 June 2016 (UTC)
• Support given renaming announced is all over Apple's website. Blythwood (talk) 07:24, 14 June 2016 (UTC)
• Support; waiting until fall is just needlessly delaying the inevitable. – Srdjan m (talk) 09:09, 14 June 2016 (UTC)
• Support per Srdjan. John123521 (Talk-Contib.) RA 11:30, 14 June 2016 (UTC) John123521 (Talk-Contib.) RA 11:30, 14 June 2016 (UTC)
• Support move to either MacOS or Mac OS - probably the former.  ONR  (talk)  12:15, 14 June 2016 (UTC)
• Support move to macOS. We'll need good disambiguation stuff on that page and on Mac OS, though. —ajf (talk) 15:04, 14 June 2016 (UTC)
• Oppose for now: as others have said, this should happen but not until the first release that uses macOS is public. Liam McM (Talk|Contribs) 16:53, 14 June 2016 (UTC)
• Oppose: The name will not be mac OS untill Serira comes out in the fall; El Capitan is still the current version so the name is still OS X, and mac os really should get it's own article at the time of releace. KDTW Flyer (talk) 20:09, 14 June 2016 (UTC)

No, "Mac OS X", "OS X", and "macOS" are the same operating system, and should all be on the same page. Guy Harris (talk) 00:10, 15 June 2016 (UTC)

• Oppose: no need to hurry. Uziel302 (talk) 21:15, 14 June 2016 (UTC)
• Oppose: Existing versions of the OS are still called "OS X" (see http://www.apple.com/osx/). "macOS" is only used for Sierra, which is not released for consumers at this time. Trinitresque (talk) 22:57, 14 June 2016 (UTC)
• Support per Srdjan m. Chase (talk | contributions) 23:46, 14 June 2016 (UTC)
• Strong support Official name. --Proud User (talk) 14:45, 15 June 2016 (UTC)

• Wikipedia uses the most commonly used name, not the official name. That something is the "official name" is not cause to change the article's title. - Aoidh (talk) 02:01, 16 June 2016 (UTC)

• Oppose - As OS X is still overwhelmingly the common name. Especially when taking into account Trinitresque's assessment that macOS is not used for any available version of this software but rather a future version, there is no cause to change the article's title at this time. - Aoidh (talk) 02:03, 16 June 2016 (UTC)

So when would the right time have been to rename Mac OS X to OS X? When Mountain Lion was released, or after a few more releases came out with the name "OS X"? Guy Harris (talk) 02:40, 16 June 2016 (UTC)

• Strong Oppose for now. Strong Support when released. Wikipedia is for the current state of affairs - and the current product is OS X. We can mention the upcoming change of name, prepare to rename this page on the day of release, but should not be renamed before that point. Cheers, Dresken (talk) 03:34, 16 June 2016 (UTC)
• oppose for now, till at least macOS is officially released and so becomes the name by which it is generally known.--JohnBlackburne^words_deeds 12:06, 16 June 2016 (UTC)

Presumably meaning "till at least macOS Sierra is officially released"; "Mac OS X"/"OS X"/"macOS" are names for an OS that was first released in 2001 under the name "Mac OS X", so what will be released is the next version of that OS. (Again, emphasizing that "macOS" isn't a new OS, it's just a new name for the Same Old OS from 2001.) Guy Harris (talk) 17:20, 16 June 2016 (UTC)

• Neutral now, support when Sierra is released OS X will be the common name for a while, I imagine, but the upgrade path for macs is such that most people will be on the current version in a few months (or sooner). Protonk (talk) 19:52, 16 June 2016 (UTC)
• Support The new product name is already in use currently and has a public beta launching next month. Dane2007 (talk) 03:26, 19 June 2016 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Multiple version numbers in the infobox?

There is currently a discussion of whether Template:Infobox OS should be used with multiple version numbers - for example, to list both a "software update" and "next major release" beta, or to list betas from more than one release stream. If you believe that multiple {stable, preview} releases should never appear in that infobox, or if you believe that they should appear under some or all circumstances where there's more than one beta of the OS in question available, you might want to comment there. (I have no strong belief either way; I'm OK with the main OS page listing only the "next major release" beta, but listing betas from multiple streams if they exist, but I'd also be OK with other choices.) Guy Harris (talk) 08:07, 11 July 2016 (UTC)

Semi-protected edit request on 18 August 2016

New Public beta for macOS is out- public beta 4.

2A00:23C4:84A2:3800:2C2D:CC0E:C236:BEB2 (talk) 09:59, 18 August 2016 (UTC)

Not done: as you have not cited reliable sources to back up your request, without which no information should be added to, or changed in, any article. - Arjayay (talk) 10:33, 18 August 2016 (UTC)

Different proposal of renaming when macOS Sierra releases

The following is a closed discussion of a move suggestion. Please do not modify it. Subsequent comments should be made in a new section on the talk page.

The result of the move suggestion was: Proposal does not look like consensus for the pair of suggested moves is forming, WP:SNOW (non-admin closure) — Andy W. (talk · ctb) 19:43, 20 September 2016 (UTC)

---

As macOS no longer means Version 10 of the operating system of Macintosh, it should be better to rename Mac OS to macOS, and then rename OS X to macOS (Version 10) or something similar. -- Meow 01:27, 15 June 2016 (UTC)

• Oppose - "macOS" is one of the names for Apple's desktop/laptop/server UNIX operating system, along with "Mac OS X" and "OS X". It has never been the name for Apple's non-UN*X Macintosh operating system - when it was first given a name containing "OS" it was "Mac OS", with a capital "M" and a space between "Mac" and "OS". I don't know what the correct name would be for the page currently at Mac OS, but I don't think "macOS" would be it. I'm not sure "Mac OS" is the correct name, either, given that 1) it wasn't called "Mac OS" until System 7.6 and 2) it wasn't called anything with "Mac" in the name after Lion (and they were in the middle of the transition for Lion). On the other hand, "Macintosh system software" seems ugly and clumsy. Guy Harris (talk) 01:44, 15 June 2016 (UTC)
• Oppose per Guy Harris. – Srdjan m (talk) 06:57, 15 June 2016 (UTC)
• Oppose per Guy Harris. "As macOS no longer means Version 10 of the operating system of Macintosh", what makes you believe that?–Totie (talk) 07:04, 15 June 2016 (UTC)
• Oppose, also per Guy Harris. —zziccardi (talk) 23:02, 15 June 2016 (UTC)
• Oppose - let's wait until Sierra is released, or until Apple updates their web site with new branding. They still have an OS X page up for the current version. MFNickster (talk) 04:52, 16 June 2016 (UTC)
• Oppose Mac OS is the name of the legacy line, macOS is the renamed product. The difference in spacing and capitalization distinguish the two. Dane2007 (talk) 03:28, 19 June 2016 (UTC)
• Oppose OS X is the tenth version of Mac OS. Apple announced that they would rename OS X to macOS, not Mac OS to macOS. Since OS X is only a version of Mac OS and they renamed it macOS, that makes macOS only a version of Mac OS. Therefore, macOS ≠ Mac OS and Mac OS (Version 10) = macOS. To conclude:
  • Apple hasn't changed the name of every version of Mac OS to macOS, just the tenth one.
  • You could correctly call the tenth version of Mac OS either "Mac OS" or "macOS", but "Mac OS" is more generalized and renaming this article "Mac OS (Version 10)" would be redundant since we could be using the more common name "macOS" and be more concise, all of which is advised by Wikipedia's title policy.
  • "macOS (Version 10)" means the same thing as OS X Mavericks. This article is about all of macOS, not just OS X Mavericks.

--Proud User (talk) 21:00, 19 June 2016 (UTC)

• Weak support but largelyNeutral I don't care what it is moved to, as long as there is an obvious differentiator and does not confuse the reader. I tend to slightly prefer this proposal over renaming Mac OS macOS. - Champion (talk) (contribs) (Formerly TheChampionMan1234) 04:20, 22 June 2016 (UTC)
• Oppose Even though both Mac OS and macOS look similar but they both are different, for the latter which is resembled to iOS, which is designed for traditional computers rather than modern smart devices. Mac OS X was named to differentiate with then-current popular Mac OS 8/9, but today all the old Mac OS vanished without turning back, leaving Mac OS X only, so emphasizing X is meaningless. And definitely macOS Sierra is just the Mac OS X 10.12, so renaming it is just better than emphasizing the long passed old history! So I strongly recommend to change the term OS X to macOS, leaving the term Mac OS without changed. Computerfann (talk) 12:25, 29 June 2016 (UTC)
• Oppose A better proposal would be to rename Mac OS to Mac OS (Original Mac Operating System) or something like that and to rename this page to macOS when it releases. I did not vote in the earlier discussion but would have voted to rename this page to macOS when it releases, not before. RoyLeban (talk) 05:47, 30 August 2016 (UTC)

---

The above discussion is preserved as an archive of a move suggestion. Please do not modify it. No further edits should be made to this section.

"Mac OS" and "Classic Mac OS" pages

Please follow this link for the discussion about the restructuring of the "Mac OS" and "Classic Mac OS" pages and continue the discussion there to help us keep it in one place. Thank you! —Samvscat (talk) 20:43, 23 September 2016 (UTC)

Requested move 20 September 2016

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: moved. (non-admin closure) Regards, Krishna Chaitanya Velaga (talk • mail) 12:25, 27 September 2016 (UTC)

---

OS X → MacOS – Now that macOS Sierra has been released, the official name of the current version of the OS is "macOS", not "OS X". Guy Harris (talk) 19:47, 20 September 2016 (UTC)

• Comment: there was an RM that closed some months ago as no consensus, but it does look like situations have changed. Looks like some folks there were willing support this around this time frame. Mild support given reasoning. — Andy W. (talk · ctb) 19:52, 20 September 2016 (UTC)
• Support on the basis that macOS is the official name now that Sierra is out (http://www.apple.com/osx redirects to http://www.apple.com/macos/sierra/). However, per WP:SMALLDETAILS, I would oppose any change to the existing Mac OS article (which I've seen mentioned above in previous move discussions), which is a distinct topic and distinguished by the lack of a space. Hatnotes should be sufficient to clarify this to readers. clpo13_(talk) 20:05, 20 September 2016 (UTC)

Yes, "Mac OS" should not be confused with "macOS". (There's some discussion on Talk:Mac OS about what to do with that page.) Guy Harris (talk) 20:08, 20 September 2016 (UTC)

• Oppose I think it makes more sense to have them as separate articles. Keep OS X about the the historical operating systems that have existed under that banner, and have macOS be about the operating system going forward. Yes, it was a linear development based on the past updates, but it looks like macOS will eventually be built to mirror iOS (and there has been commentary on this in the tech press), so having them as separate articles makes the most sense to me. TonyBallioni (talk) 20:43, 20 September 2016 (UTC)

OK, so why not have separate articles for "Mac OS X", "OS X", and "macOS"? And as for the WP:OR in "it looks like macOS will eventually be built to mirror iOS", what does "mirror iOS" mean? "Get locked down as much as iOS is, with only App Store apps allowed"? Some members of "the tech press" have gone on and on about that, but it hasn't happened yet; it's all speculation, so I don't take that notion seriously. Guy Harris (talk) 20:58, 20 September 2016 (UTC)

Mac OS X and OS X both clearly have the same branding/name. This is a restart of the operating system brand for Macs, and should have a separate article in my opinion. Point taken on the tech press commentary and I've struke it. I still think having them as distinct articles makes sense, however. TonyBallioni (talk) 22:28, 20 September 2016 (UTC)

I no more think a change in the branding from "{Mac} OS X" to "macOS" signifies that the latter is different enough from the former to deserve a different page than the change in branding from Chevy II to Chevy Nova signified that the latter is different enough from the former to deserve a different page - and, in fact, both of those redirect to Chevrolet Chevy II / Nova. Guy Harris (talk) 23:04, 20 September 2016 (UTC)

The change represents a big of enough departure in branding and features that I think it warrants a distinct article starting from Sierra. The choice was clearly made to abandon the OS X brand, and OS X is notable enough on its own to merit an article on the historical operating system. TonyBallioni (talk) 00:23, 21 September 2016 (UTC)

Branding - not enough to deem it a new OS. Features - what features in Sierra constitute a "departure in features" more significant than in previous releases? Siri? Tabs are just "hey, now everybody can use them"; Auto Unlock, Universal Keyboard, etc. are just more of the Continuity stuff that showed up in Yosemite; APFS isn't there yet; the rest are small tweaks. The choice was made to change the brand, but not the OS; it's just a continuation of the OS, under a new name, just as "OS X for the iPhone" or whatever iOS 1 was called became "iPhone OS" and then "iOS" without being a new OS. It's the same OS; it's not as if everything before Sierra is now a different, "historical" OS, with Sierra being some Shiny New Thing shinier and newer than El Capitan was when it came out, or Yosemite was when it came out, or.... The only "historical operating system" is the classic Mac OS, from before Mac OS X/OS X/macOS. Guy Harris (talk) 01:16, 21 September 2016 (UTC)

Guy Harris is correct. Because "Mac OS X", "OS X", and "macOS" are simply three marketing names for different versions of the same operating system, and this article is an overview of all versions of that operating system from its inception to the present, I would argue for keeping this article together in one piece. —Samvscat (talk) 01:20, 21 September 2016 (UTC)

I suppose my contention is that OS X is notable enough under that brand name to continue as a distinct page. I understand that it is the same OS, but it seems to me that 15 years of existence using the OS X brand in some way likely makes it significant as a historical brand, even if the OS is the same. TonyBallioni (talk) 02:48, 21 September 2016 (UTC)

And it doesn't seem that way to me at all. I think it's sufficient to mention the name changes and send all references to "Mac OS X", "OS X", and "macOS" to the page for the operating system that had those three names during its history. The brand name is hardly such a significant characteristic of the OS as to make a page about the old brand names worthwhile, or to justify the splitting of the continuous history of the OS into two pages - it's not as if Sierra is some sort of radical departure from the previous versions of the OS.

The name change might be nothing more than just Apple switching from an OS name that made sense back when they were switching from classic Mac OS to the new UN*X to an OS name that makes sense long after classic Mac OS was dead and when they're calling their other OSes by names in the style of {sequence of lower-case letters indicating the platform on which it runs}OS. I.e., it's not necessarily indicative of some Signifcant Change; maybe they changed it just because "that was then, this is now, and maybe we should have done it several releases ago, but we're getting around to it now". Guy Harris (talk) 03:25, 21 September 2016 (UTC)

• Support: I believe that reliable sources are usually quick to adopt such name changes. Therefore I think it is alright to do it now.–Totie (talk) 21:04, 20 September 2016 (UTC)
• Weak oppose for now. Policy says that WP:COMMONNAME controls in spite of WP:OFFICIALNAME. Right now, OS X is the common name. It's true that in time, macOS will likely become the common name as well as the official name. Until then, it seems that OS X should remain. Ergo Sum 21:58, 20 September 2016 (UTC)

My RSS feeds are already showing articles talking about "macOS Sierra"; how long do we wait? Guy Harris (talk) 22:01, 20 September 2016 (UTC)

• Support: There is a precedent for this move: upon the previous branding change of this operating system from "Mac OS X" to "OS X", the article was renamed as such and continued to serve as an overview of the entire OS. Now with the most recent change from "OS X" to "macOS", it would make sense to do the same. —Samvscat (talk) 01:20, 21 September 2016 (UTC)
• support as its current and formal name. It may seem early with the bulk of sources still referring to it under older names, but they are and will become increasingly historic, making this the natural time to do it.--JohnBlackburne^words_deeds 01:25, 21 September 2016 (UTC)
• Support - macOS is the current name for OS X. Yoshiman6464 (talk) 02:16, 21 September 2016 (UTC)
• Support - macOS is now officially the name of Apple's desktop operating system and the article should reflect that in the title. LocalNet (talk) 04:58, 21 September 2016 (UTC)
• Support - macOS has become the current name for the operating system previously known as OS X. Someguy432 (talk) —Preceding undated comment added 08:11, 21 September 2016 (UTC)
• Support - it is the current name of the product. The common name argument is completely subjective: Apple owns the trademark, they determine what it's called, it's not by popular vote. Lexlex (talk) 09:02, 21 September 2016 (UTC)

Determining the common name is certainly not completely subjective and Wikipedia does have guidelines for establishing this: look at the usage in reliable, secondary sources. How Apple calls it or what the trademark is are only supporting factors, they is not determinative per Wikipedia naming conventions. Wikipedia also does not decide based on popular vote, but on consensus.–Totie (talk) 09:55, 21 September 2016 (UTC)

• Weak support per WP:NAMECHANGES. SSTflyer 10:25, 21 September 2016 (UTC)
• Comment. I am nost sure why this (or rather MacOS is listed at Wikipedia:Redirects_for_discussion/Log/2016_September_21#MacOS by User:NasssaNser. The redirects will be taken care of depending on the result of the discussion; the existence or absence of a redirect of itself is not an argument for or against the move, and does not seem to hace been an issue during this discussion. Just trying to tie the two together. Si Trew (talk) 13:44, 21 September 2016 (UTC)

  Thanks for catching this. I've given the RfD a procedural close, since it was a move request. --BDD (talk) 14:07, 21 September 2016 (UTC)

• Support per nom. (Oops, thanks, BDD) NasssaNser_{and his edits} 14:14, 21 September 2016 (UTC)
• Oppose macOS should refer to all the Macintosh system software going back to 1984, which is already known as Mac OS. The "Mac OS" branding predates Mac OS X, going back to version 7.6, so it is really confusing to have macOS refer only to OS X. Is Apple's actual position that macOS=OS X and Mac OS=the older versions? That would be really confusing (and more so because wiki software doesn't distinguish macOS and MacOS). It's as if Microsoft renamed Windows to winDows but retroactively applied the new name only to the versions after XP. We could do something like macOS (10.x) instead. 2601:98A:4001:1544:B0A1:4096:EE42:7499 (talk) 15:40, 21 September 2016 (UTC)
  • The spacing is important. As far as I can tell, "Mac OS" (space) has been used as an all-encompassing term to describe the operating systems distributed on Apple computers, while "macOS" (no space) is a new term used for the latest iteration of OS X (10.12). It's similar to how iOS used to be named iPhone OS but the new term is now applied retroactively (or how OS X used to be Mac OS X). You're right that the software doesn't distinguish between capitals at the beginning of a word (macOS and MacOS are the same article), but it does distinguish other details, such as spaces or different capitalization after the first letter (see WP:SMALLDETAILS). So, macOS/MacOS is distinct from mac OS/Mac OS), just as Windows is distinct from winDows. Readers who end up at the wrong page are directed to similarly-named ones via hatnotes. However, since the naming is potentially confusing, there's a separate discussion going on at Talk:Mac OS regarding the purpose and naming of that page. clpo13_(talk) 15:47, 21 September 2016 (UTC)
    • I'm not sure Apple bothers to have a position, other than "Why do you care about the name of an OS that we obsoleted 15 years ago? We called that OS a bunch of different names, ending with "Mac OS" when we were licensing it to clone makers. Then we called our UNIX-for-Macs "Mac OS X" when we released it to emphasize its connection to the old OS named "Mac OS". Now we call it "macOS" to emphasize its connection to our other OSes." Guy Harris (talk) 19:02, 21 September 2016 (UTC)
    • Why not retroactively rename all the Mac OS's to macOS? That would be simpler. Has Apple explicitly said to the contrary? 2601:98A:4001:1544:2945:9B90:920D:960F (talk) 16:01, 21 September 2016 (UTC)
      • Because we don't own them and don't get to arbitrarily decide what their names were. Guy Harris (talk) 19:02, 21 September 2016 (UTC)
• Support – Per WP:NAMECHANGES. Most (if not all) major sources have been routinely using "macOS" instead of "OS X" after the name change was announced at WWDC. – Srdjan m (talk) 16:16, 21 September 2016 (UTC)
• Support - The settings app in the iCloud web interface refers to devices "running macOS Yosemite", suggesting that macOS can apply to releases before Sierra. (screenshot) Rotanagol (talk) 19:18, 21 September 2016 (UTC)
• Support - The official name is macOS, and most places have begun to use macOS rather than OS X. Sonictrey (talk) 21:16, 21 September 2016 (UTC)
• Support - The OS is the same (the topic of the article) but the name has been altered. It only makes sense to update the name instead of creating a new article Horseloverfat (talk) 22:35, 21 September 2016 (UTC)
• Support - it's time. Blythwood (talk) 05:24, 22 September 2016 (UTC)
• Support - All the arguments against renaming are, in my opinion, quite weak. Thatkitten (talk) 07:31, 22 September 2016 (UTC)
• Support - WP:NAMECHANGES seems to apply here. There's no need to split the article - the topic for content is the same. Dresken (talk) 10:37, 22 September 2016 (UTC)
• Support: all the reasons given above are accurate. After all after Mac OS X was renamed OS X this article was also renamed, so it seems fitting that after OS X is renamed to macOS this article should be renamed accordingly. Brenton (contribs · email · talk · uploads) 20:21, 23 September 2016 (UTC)
• Support – Per WP:NAMECHANGES - Most sources go by MacOS so we should follow suit. –Davey2010^Talk 20:25, 23 September 2016 (UTC)
• Support – Any users that doesn't know of the official name change will now immediately know so via future redirects from "OS X". — AYTK talk. 20:42, 23 September 2016 (UTC)
• Support - Per WP:NAMECHANGES, the official name is now "macOS".
• Support - And I only just realised that today that 20th September 2016 is release time for macOS Sierra. Qwertyxp2000 (talk | contribs) 23:03, 23 September 2016 (UTC)

And plus, you could state that originally named "OS X" or something. Qwertyxp2000 (talk | contribs) 23:04, 23 September 2016 (UTC)

• Support - If I recall correctly, the general feeling in the last RM a few months back was that we should wait until the name change is made official (i.e. upon the release of Sierra). Now that the name change has been effected, the move can occur. Additionally, WP:NAMECHANGES is correctly cited above. Mz7 (talk) 02:58, 24 September 2016 (UTC)
• Weak Support - have to make sure the two articles are clearly distinguished form each other. Emphrase - 💬 | 📝 08:44, 24 September 2016 (UTC)
  • Which two articles? Guy Harris (talk) 18:13, 24 September 2016 (UTC)
    • Didn't realise the "classic" Mac OS article was moved. I guess it's fine now. --Emphrase - 💬 | 📝 05:55, 25 September 2016 (UTC)
• Support - In my opinion, it makes sense to migrate to a page title of macOS rather than OS X to keep in line with the recent changes to the brand name formatting made by Apple. It also seems at this point that there's overwhelming support for the change, with only a handful of opposition statements. ---- Dustin Dauncey (talk) 09:31, 24 September 2016 (UTC)
• Support - At this given time macOS redirects to this page and the existing page for Mac OS (classic) has been renamed. Seems normal to rename it to be consistent to naming convention. TempTTC (talk) 23:59, 24 September 2016 (UTC)
• Support - [I changed "Mac OS X"->"OS X" on a lot of pages at the time, and now Harris is. He generally knows computer history, and Apple in particular.] comp.arch (talk) 14:12, 25 September 2016 (UTC)
• Oppose per WP:NAMECHANGES. We don't automatically change this just because the company changes the official name. OS X has been around for a very long time, is a well established name, and we should only change if it is overwhelmingly clear that common usage has changed. Right now, "OS X" has twice as many news hits as maxOS. Thousands of computers still have "OS X" installed on them, and just because Apple have changed the name for new editions, does not automatically mean the old versions are no longer called that. See Talk:Infiniti M for a move request which concluded exactly that - the "old" name was retained despite a recent rebrand. Thanks  — Amakuru (talk) 10:12, 27 September 2016 (UTC)
• Comment and depsite the fact that there are a lot of "support" votes above, I'm not seeing much evidence. Many of those supports say that the "official name" has changed, which is mostly irrelevant per WP:OFFICIALNAME, while others say that the common name has changed without giving any evidence. Most of those !votes should be disregarded. Evidence is key.  — Amakuru (talk) 10:24, 27 September 2016 (UTC)

However a lot of articles already changed to use "macOS" instead. NasssaNser (^talk/_edits) 11:22, 27 September 2016 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

"macOS 10 redirects here" in hatnote

I hate undoing anyone's edits (I know how I feel when my own are undone!), but in the interest of keeping the hatnote as brief as possible, I don't think we need "macOS 10 redirects here. For the tenth version of the macOS operating system, see OS X Yosemite." The justification for the "Mac OS X redirects here" line is that hundreds of pages still link here through Mac OS X, which was originally marketed as the "tenth version" of what is now known as the classic Mac OS. However, no pages link to macOS 10, and "macOS 10" was never a term used by Apple. Also, there is a section dedicated to OS X Yosemite within this article. Thanks :), Samantha –Samvscat (talk) 00:47, 3 October 2016 (UTC)

I agree; I thought about removing it myself when I first saw it. If someone somehow gets here, through a search or a link, via the macOS 10 redirect, then they could be looking for any of the versions, as they are all "macOS 10.?" for some ?, or none in particular. It was or has never called macOS 10 by Apple as that would be confusing.--JohnBlackburne^words_deeds 02:19, 3 October 2016 (UTC)

Semi-protected edit request on 12 October 2016

"limitations" has a spelling mistake in the "Following releases" section.

GiorgosKeramidas (talk) 04:00, 12 October 2016 (UTC)

Done. Guy Harris (talk) 07:36, 12 October 2016 (UTC)

Semi-protected edit request on 16 November 2016

It is worth noting that macOS Sierra is also UNIX: http://www.opengroup.org/openbrand/register/brand3627.htm

2601:602:9400:407C:34D5:F6B6:B0B5:73EE (talk) 22:14, 16 November 2016 (UTC)

This request as written is not easily actionable. If you know where you want this text, specify it, and a someone else will be able to act accordingly, thanks — Andy W. (talk) 22:25, 16 November 2016 (UTC)

The article says

UNIX 03 certification was achieved for the Intel version of Mac OS X 10.5 Leopard and all releases from Mac OS X 10.6 Snow Leopard up to the current version also have UNIX 03 certification.

What more needs to be said? "The current version" is Sierra, and the certification for Sierra is given as the first of the many references for the "Snow Leopard up to the current version also have UNIX 03 certification". Guy Harris (talk) 23:00, 16 November 2016 (UTC)

Remove the "10.12" from name

A search on Apple web site for 10.12 does not reveal the new "macOS Sierra" This strongly suggests that Apple wants to do away with the numbers, possibly due to "Windows 10".
Compromise title "5.14 macOS Sierra (10.12)" Flightsoffancy (talk) 15:36, 26 September 2016 (UTC)

If you search for

"10.12" site:apple.com

in Google, a whole bunch of pages mentioning Sierra show up on the Apple Web site, including, for example, "About the security content of macOS Sierra 10.12". So there's nothing to suggest that Apple wants to do away with the numbers, and there's no reason to remove "10.12" from the name. Guy Harris (talk) 17:03, 26 September 2016 (UTC)

It reveals Apple is naming it "macOS Sierra 10.12", continuing the less dominant position of number after name.

Besides that, those results are on the Development and Support, not Apple proper with 0 results.

And using a separate search site for results masks Apples intent.

Try Apple Search on 10.12 instead

Flightsoffancy (talk) 19:02, 26 September 2016 (UTC)

"Continuing", as it "Apple isn't changing anything", hence no reason to change any page.

And the majority of hits for Apple Search on 10.11 are "on the Development and Support, not Apple proper", so, again, this isn't some Shiny New Apple Policy.

We don't do original research and use that to speculate on Apple's intent, so, no, there is no good reason whatsoever to display Sierra any differently from other releases, other than to call it "macOS" rather than "OS X". Guy Harris (talk) 19:45, 26 September 2016 (UTC)

This is not "original research", this is directly what Apple is posting on its web site. Every iteration of OS X before Sierra had some mention of "X" and maybe "10.xx", but not Sierra. Look at El Capitan, the OS X is everywhere.

This is the same debate as the "iPad 3" where many assumed because it came after iPad 2 it would be named such. In the end iPad3 was dropped because not the what Apple officially called it (even though there was some internal Apple reference to iPad 3).

No offense but your view is biased to the past 15 years of OS X, take a second look at Apple's name change. Sincerely --Flightsoffancy (talk) 15:07, 4 October 2016 (UTC)

"Every iteration of OS X before Sierra had some mention of "X"" Yes, that's because every iteration of the OS before Mountain Lion still had the name that Apple gave it when they introduced it, presumably in order to make people think of it as a successor to Mac OS 9, and every iteration from Mountain Lion to El Capitan had the name that Apple gave it when, for whatever reason, they decided to drop the "Mac" from the name but leave the "X". Sierra has the name that Apple gave it recently, presumably in order to make people think of it as a sibling to iOS and tvOS and watchOS.

None of which has anything to do with dropping the version number. Note that 10.0 through Lion were called "Mac OS X 10.{whatever}", and Mountain Lion through El Capitan were named "OS X 10.{whatever}", i.e. two "10"s. Now there's only one "10", the one in the version number.

So, again, you've failed to come up with any evidence that Apple has any "intent" to stop using version numbers, and have thus failed to come up with any reason whatsoever to "Remove the "10.12" from {the} name".

No offense but your view is biased to the notion that you've actually come up with an idea of what Apple's intent is, take a third look at Apple's continued use of a version number, and stop trying to do Kremlinology on Apple at Wikipedia - if you want to indulge in InfiniteLoopology, start a blog and join the large group of people who think they can figure out Apple's intent by seeing who's standing next to Tim Cook at WWDC. Sincerely Guy Harris (talk) 16:51, 4 October 2016 (UTC)

Frankly, I show my support on you first! "X" in Mac OS X and OS X implies many things around, not only denoting it is the tenth version of Macintosh OS or Mac OS. In the early days when Mac OS X was released, it reflected two other important things, NeXT and cross. Apple once tried to design a modern OS based on microkernel before Jobs' return, but that project eventually failed, mainly because the original design of Macintosh is mainly focusing on the hardware rather than the system software, many low level OS resources are firmed in the hardware. System software heavily utilize those firmed resources. But after Jobs' return, things happened to change, the design of new Mac put an up-side-down way, put most focus on the software rather than the hardware itself, especially affected by the Jobs' NeXT design. They adapted the Mac OS onto the layer above NeXT, for coming with time, they also replace the BSD UNIX layer with partial FreeBSD core. So the eventually Mac OS X is a product of Mac OS crossed NeXT, and NeXT is also crossed with FreeBSD rather than BSD UNIX. X emphasized the cross. Reading the book, Steve Jobs by Walter Isaacson, one could also understand Jobs have not too much passion on the PowerPC processor, for its performance and price, one clear sight embraced all the time is the transition, from PowerPC to IA-32. So since the day before Mac OS X released, there existed an 80486 fork. So "X" denotes the process of transition, from Mac OS to Mac OS X, from 32-bit to 64-bit, from PowerPC towards Intel and eventually towards x86_64. The very last version supporting Power PC applications is Mac OS X 10.6, while the last version supporting IA-32 kernel extensions is Mac OS X 10.7. Since OS X 10.8, there is noting related with the classic Mac OS, and the graphical interfaces distracts from which further and further. Until the day macOS Sierra released, it turns almost to be completely another OS. There does not exist transition or cross at all. Its nature happened to change and become a whole. So the "X" has been eliminated in its name convention. This macOS is not yesterday's Mac OS, Mac OS X and/or OS X, macOS Sierra is just macOS Sierra, a new restart product accompanying with iOS, but for traditional computing devices. So 10.12 is no more its version number. The exact version of macOS Sierra is just Sierra (mountain)! --- Neweganaj Noraa — Preceding unsigned comment added by 119.53.111.222 (talk) 13:10, 4 December 2016 (UTC)

More on hatnotes

Both the current macOS and the Classic one are from Apple and for Macs; saying so in the hatnote is pointless, as it does not help clarify the ambiguity, which is the sole reason for putting a hatnote. Readers who don't know what macOS is will learn it in the first line of the article; readers who are looking for the Classic macOS article already know it's from Apple. For the same reason, there's no need to specify the full time range. --Deeday-UK (talk) 11:42, 3 December 2016 (UTC)

Hello

An {{about}} hatnote must be self-contained. Its objective is to help the reader decide whether he or she is on the right article before the reader start reading anything else. Think about it: If the reader was supposed to read the lead (and carefully too) the whole point of the hatnote would have been moot. ("Moot". I must really get used to the American sense of this word.) This is specifically correct about the {{about}} because {{about}} is used in a situation where {{Distinguish}} is deemed insufficient.

Best regards,

Codename Lisa (talk) 12:50, 4 December 2016 (UTC)

@Codename Lisa: that's understood. The point is that the ambiguity here is between two very similar and closely related things. The hatnote is exclusively for the benefit of those readers who are looking specifically for the Classic Mac OS article, letting them know that they are on the wrong article; to tell them that the current macOS is made by Apple for Mac computers is a waste of their time; they already know it.

Readers who don't know what macOS nor Classic Mac OS are, are most likely already on the correct article and can gladly carry on reading. To quote from WP:HAT, "Keep explanations to a minimum; only explain vital information, trusting instead in the article lead to clarify things for the reader". --Deeday-UK (talk) 23:34, 4 December 2016 (UTC)

Not necessarily true. There are readers who know next to nothing about the subject and only when they reach the hatnote, they realize that they are at a cross road. I know this because it has happened to me: I now very little about Mac and its ecosystem.

The quote from WP:HAT does mention "vital information". The phrase "This article is about the current operating system" is systematically vague (and even goes against WP:DATED). It already lack vital information that WP:HAT has requested.

Best regards,

Codename Lisa (talk) 07:11, 5 December 2016 (UTC)

Of all the readers who know next to nothing, how many do you think will skip the article and follow the link to Classic Mac OS? I'd say very few; whereas the longer the hatnote, the more time all other readers will waste reading it (on an article that already has two hatnotes). It's not for the hatnote to tell the reader what the article is about; that's for the lead. The hatnote should only say what the article is about that makes it different from the other, ambiguously titled article.

Your hatnote would be appropriate if the Classic Mac OS was, for example, a burger (This article is about the Apple operating system for Mac computers. For the burger, see Classic Mac OS), but in this case it's just unnecessarily wordy. After all, were you not happy with the previous hatnote, (Not to be confused with Classic Mac OS), which by contrast was unnecessarily concise? --Deeday-UK (talk) 09:53, 5 December 2016 (UTC)

"how many do you think will skip the article and follow the link to Classic Mac OS?" That's a question for those who want to delete the hatnote. So long as the hatnote itself is kept, systematic vagueness is inexcusable. Best regards, Codename Lisa (talk) 11:49, 5 December 2016 (UTC)

There is no point wasting time to argue about this. Codename Lisa's hatnote is very good and I'm sure most other users would agree. Move on? Kosmosi (talk) 11:52, 5 December 2016 (UTC)

My only complaint is it's too long. I'd recommend "For the original Macintosh System (prior to 2001) see Classic Mac OS" MFNickster (talk) 00:32, 6 December 2016 (UTC)

Like this?

For versions released before 2001, called "Mac OS", see Classic Mac OS.

Codename Lisa (talk) 10:57, 6 December 2016 (UTC)

We are swinging from one extreme to the opposite. the 'For' template is arguably appropriate when the vast majority of readers already know what the article title is about. This is probably not the case for 'macOS', which is why I would argue the 'About' formula is more suitable. It doesn't have to be a long sentence though; in particular it doesn't have to state the obvious (such as that the OS covered in an article titled Classic Mac OS is called 'Mac OS') and it can use fewer words to give a time reference. Of course it could be trimmed down even more than this, although apparently that would make it inexcusable. --Deeday-UK (talk) 22:49, 6 December 2016 (UTC)

Version number

The non-beta of 10.12.2 should be 16C68. Jacksonzwang (talk) 16:56, 18 December 2016 (UTC)

Done. (Apparently the 2016-12-13 update was 16C67, and the combo update wasn't updated on 2016-12-14, only the Mac App Store update, according to the macOS Sierra page.) Guy Harris (talk) 19:53, 18 December 2016 (UTC)

Requesting Pronunciation Guide for "macOS"

How is "macOS" pronounced? Is it still as "Mac OS" (MAAK OH EHS), or differently (e.g. MAAKohs)? I would guess the former way. Would the addition of a simple pronunciation guide to the article be useful or unnecessary? — Erdavis7 (talk) 14:25, 6 January 2017 (UTC)

"O" and "S" are pronounced separately, not as "ohs". Pronunciation added to the article, complete with citation of the keynote with Craig Federighi pronouncing it. Guy Harris (talk) 11:28, 7 January 2017 (UTC)

The poor orphaned Unix with no family

Hello, everyone

I thought I had seen every frivolous things there is on Wikipedia, but it seems a record can still be set.

In revision 760561484, Guy Harris proclaimed that we should list macOS as a family member of Unix because otherwise Unix would have no family! I don't know about you, but I find no Wikipedia policy that sanctions taking pity on a lifeless abstract concept like a software name. (Just for the record, there is no Wikipedia policy sanctioning any edit done out of pity.)

To my extent of knowledge, however, there is no literature extending the family metaphor beyond the brand name to the derivative products. If there is, please show me. (Remember, the burden of the proof is on the person who makes a claim.)

But let's take a moment to realize what messy claims can be made based on extension of the family metaphor to derivative products: Google Chrome, Safari and Opera can be called a family on the pretext of their derived sources (WebKit and Blink). Independent video games can be called family because they use the same rendering engine.

Best regards,
Codename Lisa (talk) 05:48, 18 January 2017 (UTC)

You reverted this edit (which offered this citation to back it up) on the basis that it's branding that makes an OS family and not derivation. Do you have a reason behind that assertion? I don't think there's a formal definition of OS "family" but we should probably start with defining that term. MFNickster (talk) 06:15, 18 January 2017 (UTC)

@MFNickster: The source says "family tree" not "family". If have noticed, a family tree often contains several sometimes unrelated families whose members can safely marry each other. That's why I felt the source was WP:SYNTH.

In case of "family", this is a metaphor, not definition. Drawing on high school educations, in case of metaphor, one should understand the ground for metaphor, which in this case, is relatedness by title.

Best regards,

Codename Lisa (talk) 06:36, 18 January 2017 (UTC)

Okay, that makes sense. Looking at the Infobox OS template, it specifies "The name of the family of operating systems that this version is a part of. Examples include 'Microsoft Windows', 'Unix-like' and 'Mac OS'; 'Linux' and 'Mac OS X' are not OS families." There isn't any further elaboration, but I don't see how 'Unix-like' meets any standard of branding. MFNickster (talk) 06:46, 18 January 2017 (UTC)

Touche! —Codename Lisa (talk) 07:16, 18 January 2017 (UTC)

I found people who can probably answer our question. The original claim was added on 4 August 2009 by Skyerise. The new claim is added on 11 July 2014 by Netoholic. Maybe they should explain what makes "Unix-like" a family.

Best regards,

Codename Lisa (talk) 07:24, 18 January 2017 (UTC)

My apologies. The new claim is not added by Netoholic. It is added on 10 April 2013 by none other than yours truly! Strange, because around that time, I was of the opinion that Unix-like is not a family. Still, it is probably as I wrote: I was interpreting the consensus in the talk page which was not corresponding to my personal opinion.

Best regards,

Codename Lisa (talk) 07:39, 18 January 2017 (UTC)

OK, if we're going to ask what belongs, and what doesn't belong, to the "Unix" family:

"Unix" was originally a Trademark of Bell Laboratories, and referred to various operating systems from AT&T, such as the operating system whose manual was called "The UNIX Time-Sharing System, Sixth Edition", the operating system whose manual was called "The UNIX Time-Sharing System, Seventh Edition", "UNIX, System III", "UNIX, System V", etc..

Some vendors took the source code to those versions of UNIX and produced derivatives. Most of them had names other than "UNIX"; AT&T was, at times, somewhat insistent on protecting their trademark. When I was in the core OS group at Sun, we changed SunOS to say, in the boot message, "SunOS" rather than "Sun UNIX 4.2BSD", as a result of AT&T complaints.

In 1988, AT&T licensed the UNIX trademark to "vendors who base their products on AT&T's UNIX System V Release 3.2 and who meet AT&T's trademark license requirements", allowing them to "use the trademark UNIX in the names of their products." The rights to the trademark passed on to UNIX System Laboratories, an AT&T subsidiary, and then to Novell when they bought USL. As I remember, systems that passed the validation suite for the System V Interface Definition met the trademark license requirements; I am not certain whether, to meet the trademark license requirements, the system had to be based, to some degree, on AT&T's System V code (this was at the end of my time at Sun; I was a bit burned out from dealing with AT&T), but I think it did.

Later, Novell transferred the trademark to X/Open, who licensed it to vendors whose systems passed the Single UNIX Specification test suite, regardless of whether the system had any AT&T code at all. X/Open ended up merging with the Open Software Foundation, creating The Open Group, to whom the trademark passed.

Of the systems licensed with the UNIX 95 brand, only SCO UnixWare has "Unix" (with any capitalization) in the name.

Of the systems licensed with the UNIX 98 brand, none of them have "Unix" (with any capitalization) in the name.

Of the systems licensed with the UNIX 03 brand, none of them have "Unix" (with any capitalization) in the name.

At one point, Digital/Tru64 UNIX was licensed with one of the brands, but The Open Group is no longer listing it.

So, if there is to be a "Unix" family at all, some possible groups of members are:

1. All OSes that AT&T released as "UNIX";
2. All OSes in that category plus all OSes derived from one of those OSes;
3. All OSes with "UNIX" in the name;
4. All OSes that ever were given Open Group "UNIX" branding.
5. All OSes that are "sufficiently" compatible with some flavor of UNIX.

No current OSes are in the first or third category; if that is deemed to be the "Unix" family, we should remove Solaris, HP-UX, and AIX from that family, even though all three of them are branded as UNIX. At least it's easy to determine what OSes are in one of those categories, but the third is a silly category, as there's no good reason why Digital/Tru64 UNIX is, from the point of view of anybody other than trainspotters, any more a "Unix" than Solaris, HP-UX, or AIX.

All of those, and a ton of now-dead OSes, are in the second category. It's certainly an interesting category, but, unfortunately, determining whether an OS is in that category might be more difficult, and finding citations for that determination even more difficult.

The fourth category is also an interesting category, and it's relatively easy to find citations, although digging up citations for some of them http://web.archive.org/web/20040115013950/http://www.opengroup.org/openbrand/register/xu.htm may involve the Wayback Machine]. For macOS, it's not at all hard to a citation for every version going back to Leopard (the first version to receive the UNIX brand) - they're all references on that page.

The fifth category is also interesting, but even harder to define with references.

So pick one of those five (but be prepared to get pushback if you choose the first or third), come up with another one that makes sense, or kill the "Unix" family entirely. Guy Harris (talk) 09:43, 18 January 2017 (UTC)

So, the gist of what you say is: Please take pity on Unix that has become family-less because of the mistake of AT&T. Oh, poor Unix!

You are more than welcome to add all this to the article prose but other than that, per WP:NPOV, we don't cover up the corporate mistakes that ultimately shaped their role, impact and market share of their products just to fill up a |family= in the infobox. Quite frankly, we do the exact opposite, i.e we exhibit those mistakes naked, fairly, proportionately and as much as possible without bias.

Best regards,

Codename Lisa (talk)

This has nothing to do with any alleged corporate mistakes. It has to do with, among other things, the fact that a number of operating systems that don't happen to be sold as, for example, "Apple UNIX for Macintosh" or "IBM UNIX" or "Hewlett-Packard UNIX" or "Oracle UNIX", happen to share a significant subset of their programming and command-line user interfaces and, in the cases of the OSes to which I'm alluding there (macOS, AIX, HP-UX, Solaris), what they share is covered by the Single UNIX Specification, and, given that they've all passed the validation suite for that specification, the vendors of those OSes are allowed to use the trademark "UNIX" when speaking of them about them, even if they don't use it in the name. See, for example, IBM's AIX page, Hewlett Packard Enterprise's HP-UX page, and this Solaris 11 page at Oracle, all of which speak of the operating system in question as a "UNIX operating system", and the "open source" page on Apple's developer site, which says that "OS X" (they have not yet updated the page for the new name for the OS; I'll send them a note to do so) "combines a proven UNIX foundation with the easy-to-use Mac interface".

And, as for the claim that "the ground for metaphor" is, "in this case", "relatedness by title", the burden of the proof is on the person who makes a claim. Guy Harris (talk) 11:57, 20 January 2017 (UTC)

Well, allow me to be frank, I go agree with this Kawaii lady, especially for her words, "Oh, poor Unix!"

When we talk about a family, we must have the clear clue about its members who are the preceding and who are the following. But in essence, Mac OS X/OS X/macOS has only the hold of Open Group UNIX certification and/or the brand, rather than the real member of a UNIX. The direct ancestor of macOS is NeXT, which is not a member of UNIX too. They just borrow the ideas of UNIX, rather than have already become part of it. Because there is no codebase from AT&T UNIX in their products. macOS is not a continuing version of UNIX, or in other words, it is not the following of that family. Apple just made their product based on this supporting layer (made good use of/utilised), rather than continued this already extinct family. So it is not a member of UNIX! Obviously, Mac OS X is the following member of Mac OS 9.22, and OS X is the rename of Mac OS X. Last year, Apple made a second rename for re-positioning their products on the market, with macOS Sierra as its current release. People speaking English do not mean they are the members of British, they are just what they are, even they hold the visa or have been living in Great Britain for a long period...

Best Regards,

Aaron Janagewen — Preceding unsigned comment added by 119.53.105.152 (talk) 04:22, 21 January 2017 (UTC)

There is essentially no UNIX left that has any codebase from AT&T UNIX, it's effectively dead. However, since BSD forked from AT&T UNIX and Mach forked from BSD and NeXT forked from Mach, it's not unreasonable to say MacOS derives from UNIX. Technically, it's a hybrid of UNIX, Mach, NeXT and Apple technologies, but Darwin at the core is every bit as much a BSD as FreeBSD, NetBSD and OpenBSD are. MFNickster (talk) 04:49, 21 January 2017 (UTC)

Wow, what a spectacularly pointless piece of bikeshedding! Rather than going back and forth about the "one true meaning" of "the Unix family", let's take a step back and ask the more fundamental question: what information is useful to readers?

Is it useful information to group macOS with Solaris and HP-UX as a certified Unix OS; or perhaps with GNU, Linux, and MacOS's close cousins such as OpenBSD as a "Unix-like" OS? In my opinion, the answer is yes, this part of its origin is fairly fundamental, and deserves to be summarised in the infobox.

I'd also go so far as to say that if it *isn't* in the Unix family, then it's not in the "Macintosh" family either. The fact that it shares its name with a previous OS seems less relevant than what OSes it is "related to" in terms of technology, and it probably shares less code with classic MacOS than it does with other Unix-like systems. - IMSoP (talk) 18:06, 12 February 2017 (UTC)

Mac OS X is a cross between classic Macintosh OS and NeXT, in other words, that is a re-presentation/re-implementation of classic Macintosh OS on NeXT platform. Something similar as Windows NT, which is a re-presentation of Windows on NT platform. Combining two very different kinds of things together would easily confuse some beginners, mistaking A+B as merely A or B. NeXT is further replaced by many similar things from levels under Mac OS X, and this Unix-Like layer has already become one comprising part of Mac OS X, supporting the upper and real Apple products. The meaning of Unix in Mac OS X has become to change decades ago, or in other words it has evolved itself, apart from the true nature of Unix further and further away. So Mac OS X should not be sorted into the Family of Unix, because the real interface between users and Mac OS X system is the GUI interface provided by Apple rather than CSH, BASH, KSH and so forth. And the real interface between developers and Mac OS X are also those libraries provided and evolved from NeXT and Apple rather than so many standard libraries provided by AT&T, BSD, GNU and so forth. So this thing could only be sorted into the Family of Macintosh OS. The Family of Macintosh OS or Macintosh Family does not mean the OSes designed for legacy and phased-out Apple products produced when 68k and PowerPC were popular, but also the entire Apple product lines, including iOS for Apple Smart Devices. macOS is only a rename of Mac OS X, there is no change happened to the nature of Mac OS X. --- Neweganaj Noraa — Preceding unsigned comment added by 221.9.13.70 (talk) 02:30, 24 April 2017 (UTC)

the real interface between users and Mac OS X system is the GUI interface provided by Apple rather than CSH, BASH, KSH and so forth

That depends on the user. For some of us, they're both the interfaces; after all, Terminal is part of that GUI interface....

the real interface between developers and Mac OS X are also those libraries provided and evolved from NeXT and Apple rather than so many standard libraries provided by AT&T, BSD, GNU and so forth

That depends on the developer. For some of us, they're both APIs that are used. Guy Harris (talk) 03:26, 24 April 2017 (UTC)

Renominate for GA status

In 2014 this article was demoted from GA status. The concern was that "that there is a massive number of [citation needed]s throughout. The article was promoted to GA back in 2010, and upkeep has been scant. The "features" section is also very scattershot and choppy." It seems these issues have been mostly been fixed and should be renominated for GA status. -KAP03(^{Talk • Contributions • Email}) 03:44, 17 May 2017 (UTC)

Edit Request update latest sierra release to 10.12.5

10.12.5 was released on 15 May, but the table still has 10.12.4 as the current release. No idea what the build number is, though. — Preceding unsigned comment added by 137.154.213.84 (talk) 06:42, 22 May 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 8 external links on MacOS. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://www.apple.com/itunes/download/
• Corrected formatting/usage for http://www.apple.com/itunes/download/
• Corrected formatting/usage for http://www.apple.com/support/downloads/ichatav21.html
• Corrected formatting/usage for http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore?productLearnMore=M8820Z%2FA
• Corrected formatting/usage for http://www.zdnet.com/zdnn/stories/newsbursts/0%2C7407%2C2681914%2C00.html?chkpt=p1bn
• Added archive https://web.archive.org/web/20110623030050/http://www.apple.com/macosx/whats-new/features.html to http://www.apple.com/macosx/whats-new/features.html
• Added archive https://web.archive.org/web/20061220025116/http://www.uspto.gov/index.html to http://www.uspto.gov/index.html
• Corrected formatting/usage for http://www.apple.com/macosx/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 10:17, 29 May 2017 (UTC)

App versions- Messages, Mail

Additions for App version table: Messages in 10.10 is 8.0 Messages in 10.8 is 7.0.1 Mail in 10.8 is 6.6 Mail in 10.7 is 5.3

source is VMs I have installed. — Preceding unsigned comment added by Lycestra (talk • contribs) 18:25, 8 September 2017 (UTC)

Semi-protected edit request on 26 September 2017

Please change "The latest version of macOS is macOS 10.12 Sierra, which was publicly released in September 2016." to "The latest version of macOS is macOS High Sierra, which was pubicly released in September 2017." TheComputer8423 (talk) 02:23, 26 September 2017 (UTC)

Done SparklingPessimist ^{Scream at me!} 02:36, 26 September 2017 (UTC)

References

Semi-protected edit request on 30 September 2017

Change "macOS 10.12 Sierra's main features are the introduction of Siri to macOS, Optimized Storage, improvements to included applications, and greater integration with Apple's iPhone and Apple Watch. The Apple File System was announced at the Apple Worldwide Developers Conference in 2016 as a replacement for HFS Plus, a highly criticized file system. This new file system will be implemented at a later date." to reference the implementation of the Apple File System with macOS High Sierra.

Additionally, change "The default macOS file system is HFS+, which it inherited from the classic Mac OS. Operating system designer Linus Torvalds has criticized HFS+, saying it is "probably the worst file system ever", whose design is "actively corrupting user data". He criticized the case insensitivity of file names, a design made worse when Apple extended the file system to support Unicode.[57][58] Initially, HFS+ was designed for classic Mac OS, which runs on big-endian 68K and PowerPC systems. When Apple switched Macintosh to little-endian Intel processors, it continued to use big-endian byte order on HFS+ file systems. As a result, macOS on current Macs must do byte swap when it reads file system data.[59][60] These concerns are being addressed with the new Apple File System, which is used for file systems on SSDs in macOS High Sierra." to reference that APFS is now the default file system, as of the introduction of macOS High Sierra, preferably mentioning some of it's details including that it is also the file system on Apple iOS devices and Apple Watches.

One reference to these changes can be seen on the Apple website here: https://support.apple.com/en-gb/HT208018.

Additionally, the wikipedia page on the Apple File System (APFS) can be seen here https://wiki.riteme.site/wiki/Apple_File_System#cite_note-prepForAPFS-13 with more details on APFS. Emit time (talk) 17:07, 30 September 2017 (UTC)

I've changed the Sierra paragraph to remove "This new file system will be implemented at a later date." and changed the next paragraph, on High Sierra, to indicate that it uses APFS on SSDs. I also updated the "default MacOS file system" to say that it's only the default prior to High Sierra and on non-SSD media.

There's no need to go into more detail about AFPS, given that it has a Wikipedia page and that this article links to that page. Guy Harris (talk) 18:13, 30 September 2017 (UTC)

Semi-protected edit request on 7 November 2017

format this article straight after answering. 2A00:23C4:7A88:4C00:B:94A2:1330:FAD1 (talk) 18:22, 7 November 2017 (UTC)

Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format. JTP ^{(talk • contribs)} 19:31, 7 November 2017 (UTC)

"It is the most successful Unix-like desktop operating system on the web"

a) Maybe drop this text, as Windows 10, now has a Windows Subsystem for Linux, with software from Ubuntu, in collaboration with Cannonical. Thus, is Windows to now POSIX and [Unix-like]]? It's clearly more popular, while the subsystem may be less used than in macOS (is CLI much used in macOS..?).

b) Plan b might be to say macOS is most popular UNIX-branded OS, as it has certification and Windows 10 doesn't (and only few Linux). comp.arch (talk) 12:57, 8 November 2017 (UTC)

The statement is that macOS is a "Unix-like operating system". "Windows Subsystem for Linux" is not an operating system, it's a translation layer. The article is fine as-is. Warren -talk- 14:00, 8 November 2017 (UTC)

What makes an OS Unix-like? Isn't that it's "like" Unix? I.e. can run Unix programs..? comp.arch (talk) 17:54, 8 November 2017 (UTC)

I'd go with Plan c: drop the statement entirely. While it may be true, it's an uncited editorial comment that makes unstated assumptions about what is "successful." I'd just leave the percentage figure in. MFNickster (talk) 02:34, 9 November 2017 (UTC)

I've changed it to "widely-used", which conveys the same idea without getting into the whole "success" thing. Warren -talk- 05:49, 9 November 2017 (UTC)

...and the only desktop UNIX-branded OSes, these days, are macOS and maybe Solaris x86; none of the others run on x86 PCs, and their vendors left the workstation business a while ago. As such, "most widely used UNIX-branded OS on the web" is pretty much because, to the first few orders of approximation, it's the only UNIX-branded OS on the Web; it's also the "most widely used OS on the web with a name beginning with "mac"", but that's not interesting.

The article starts out saying "by web usage, it is the second most widely used desktop OS after Microsoft Windows"; I changed the statement in question to say "It is the second most widely-used desktop operating system on the web, after Windows, and is estimated at approximately five times the usage of Linux (which has 1.01%).", which says the same thing and also compares with another Unix-like system.

As for "What makes an OS Unix-like?", as the article for the term says, "There is no standard for defining the term, and some difference of opinion is possible as to the degree to which a given operating system or application is "Unix-like"." Personally, I wouldn't count any Unix layer that isn't the "primary" OS layer, atop which most applications run, so I wouldn't count z/OS as a "UNIX-like" OS even though it has UNIX System Services, and wouldn't count IBM i as a "UNIX-like" OS even though it has PASE, and wouldn't count OpenVMS as a "UNIX-like" OS even though it has a POSIX layer, and wouldn't count Windows 10 as a "UNIX-like" OS even though it has the Windows Subsystem for Linux.

I also wouldn't count Linux, FreeBSD, or macOS as "Windows-like" even though Wine works on them, for the same reason. Guy Harris (talk) 07:42, 9 November 2017 (UTC)

Or, put more shortly, it's all about how the operating system operates, not what programming interfaces it offers to software developers. Warren -talk- 14:37, 9 November 2017 (UTC)

"Long-awaited Vista"

"Microsoft stopped providing extended support for Windows Vista on 11 April 2017". Should the article at some point stop comparing to Vista, or mention ad that do? It's like kicking an old, now dead dog. Vista got a bad rap, maybe unfairly, added security, and I believe people are fine with that legacy, as it lives on in Windows 10 (unchanged?). comp.arch (talk) 09:15, 9 November 2017 (UTC)

It mentions Vista as a target of Apple's advertising, as a way of showing how Apple promoted their OS, rather than as an actual comparison of the two OSes - i.e., it's not saying "Vista sucked, Tiger and Leopard ruled", it's saying "Apple said "Vista sucks, Tiger/Leopard rule" in their advertising". So, no, it's not kicking Vista, it's saying Apple kicked Vista, and it remains true that Apple kicked Vista, whether Vista deserved it or not, so I think that should say. Guy Harris (talk) 09:21, 9 November 2017 (UTC)

Is that a typo for, "should stay"? The mention of [non-current] "Vista" ad under "Promotion"? I think the conclusion is then to keep the wording (unchanged). comp.arch (talk) 09:39, 10 November 2017 (UTC)

"Is that a typo for, "should stay"?" Yes. Guy Harris (talk) 17:56, 10 November 2017 (UTC)