(According to wikipedia: All versions of macOS from Mac OS X Leopard to macOS 10.15 Catalina, except for OS X Lion,[68] have been registered on Intel-based systems, and all versions from macOS 11 Big Sur, the successor to macOS Catalina, to macOS 14 Sonoma have been registered on both x86-64 and ARM64 systems.)
It's not simply that certification costs money. It's that a lot of modern UNIX-like operating systems don't adhere to the UNIX spec. For example, the OpenBSD man pages specify the ways in which they diverge from POSIX and UNIX in the Standards section: https://man.openbsd.org/sh.1#STANDARDS, https://man.openbsd.org/awk.1#STANDARDS. Often times these are small deviations that might not matter to most people, but it means that they aren't UNIX.
I don't know how much it costs for the Open Group to certify an OS as UNIX compliant (if anything).
A lot of the time, things are compliant in most of the common stuff, but they might not implement all of UNIX or POSIX. Close isn't compliant, but it's enough that most people don't care. For example, do you care if your Linux disto comes with the `pax` command? Or do you just use `tar`?
Apple had started calling OS X UNIX and was being sued for calling it UNIX when it wasn't actually UNIX. They decided it'd be cheaper to do the work to make OS X UNIX compliant than to deal with the lawsuit and that's what they did. BSDs never cared about calling themselves UNIX so they never went into the nitty gritty of making themselves UNIX compliant.
I agree, though I feel compelled to post that the BSDs learned their lesson about the use of the UNIX trademark the hard way. Part of what caused the classic lawsuit between the Regents of the University of California (the "Berkeley" in Berkeley Software Distribution) and AT&T was the fact that a spinoff company selling BSD had the phone number 1-800-ITS-UNIX:
This lawsuit happened (1992-1994) when Linux was in its infancy (Linus Torvalds started work on Linux in 1991). Had the future of BSD not been so uncertain during this lawsuit, it is quite possible that some derivative of BSD would be the dominant FOSS operating system today instead of Linux.
Linux's dominance might still have emerged due to the individuals behind it. Beyond Torvalds' work on the kernel, Richard Stallman and others had a significant influence in shaping its early trajectory. Their philosophies and actions were key in driving the open-source movement forward.
The BSD license, while appealing to corporations due to its permissive nature, allows proprietary entities to incorporate the code into their products without giving back to the community. This has happened multiple times, with examples like Apple's Darwin, NetApp, QNAP, and Sony's PlayStation systems.
The GPL, on the other hand, attracted early contributors because it ensured that their work would remain open and shared with the world, rather than being exploited for profit.
Being certified Unix has nothing to do with being based on Unix code either anymore, Huawei paid for their Linux distro based on RHEL (EulerOS) to be certified Unix once.
> Being certified Unix has nothing to with being based on Unix code…
Never has. In very simple terms, it was always about standardizing OS interfaces for variant Unices. Over time, it’s moved on to be aligned with POSIX.
Historically, the US Government. NIST mandated that only those operating systems should be used where existing applications can easily be ported to and fro, and POSIX compliant OS-s tick all the boxes. Windows NT got its POSIX subsystem for this reason: https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
Most cross-platform applications for desktops and servers. If you write to the POSIX standard, it will work on a wide range of systems. Many applications don't need to go beyond that.
The brown M&M test is: can you call poll() on a terminal device?
This lack of functionality has been in existence since Mac OS X's inception. It's the reason why a cross-platform software _always_ has to support both select() and poll() to check if a user is typing on the terminal -- select() just for Mac OS X, and poll() for every other system. Wouldn't it be nice if we could standardise on poll()?
Certification aside, Linux and macOS are so similar that I only think about the difference in the rare instances where they differ: three that come to mind are xdg-open vs. open , systemd vs. launchd, and sed -i vs. sed -i ''.
GNU coreutils often have many different options than their BSD counterparts. They both (generally) share a POSIX-specified base wrt options and behavior, but if you commonly only work with one of the two, it's easy to accidentally write non-portable shell scripts.
I wonder what's the reason for Apple to do this though? Convincing more people to run a macOS server instead of a Linux/BSD one is unlikely the reason (in my mind), but it doesn't make any other sense either...
Official Unix certification may matter at workplaces and institutions where such certifications are required for meeting some type of compliance criteria. For example, if I remember correctly, early versions of Windows NT had a POSIX compatibility layer, which was crucial for getting Windows NT accepted by some US government agencies.
Still, I hope Apple resurrects their server line… hardware and software. It’d be nice to have a server oriented UNIX running on Apple Silicon without resorting to Linux.
It originally showed up in Linux, but it's pretty much universal except for MacOS. I mostly hope they start taking the "unix" part of the OS seriously again. It's been almost frozen in time.
This sounds rather dry and abstract. What I would rather like to know is: If I installed Sequoia on my x86_64 Mac, what would I lose in comparison to Ventura? I assume newer OSs increasingly drop x64 support.
I mean I know for all practical purposes that this really doesn’t mean much, but it means a lot to me; I was a big Sun guy back in the day, and a dash if Irix here and there.
Marketing. They called OS X, as it was at the time, ‘UNIX’ but didn’t pay the Open Group for certification. The Open Group sued, and Apple figured it was cheaper to certify, so they did, and have done ever since.
I love CMD because it’s part of the copy/paste shortcut but not used for any terminal control codes. So there’s no confusion about whether you’re going to accidentally SIGTERM something in the terminal by trying to copy text.
I really really wish I could have this behavior on Linux… but alas, every app under the sun chooses its own copy/paste shortcut and they all use ctrl+C/V by convention so you can’t configure it globally without rewriting every app (ok maybe you could narrow it down to a few GUI libraries like gtk/qt/etc but it’s still a huge undertaking.)
I’d settle for “ctrl-c is copy if text is selected, SIGTERM otherwise” logic, which I think Windows’s console uses, but none of the Linux terminals I’ve tried support that. I’m left with ctrl-shift-C for copy, which leaks into my muscle memory, then I accidentally use that combo in the web browser too and it opens developer tools or something. So annoying.
Shift+ins is CUA, an actual standard. Which makes far more sense than parroting Microsoft’s decision to use CTRL as a modifier, aping Mac OSs keyboard shortcuts in Windows 3.1.
That’s fine for paste, but copy is the real problem. Also, shift and insert are very very far apart from each other and are not one-handable if you’re holding the mouse with the other hand.
Copy is Ctrl+Ins, cut is Shift+Del. Looking at my ANSI keyboard, all are achievable with one hand. Though, when these were designed, GUI’s on IBM based machines weren’t really a thing and two-handed keyboard shortcuts were common-place.
With a right handed mouse it’s hard to do Ctrl+Ins with my left hand. But it’s possible, I’ll admit. It’s just pretty suboptimal given how ergonomic Cmd+C is on a Mac keyboard (thumb on Cmd is way easier to reach for than pinky on ctrl, and reaching for ctrl+Ins is harder than either.)
Yeah, mice weren’t really a thing on the early IBM AT’s and clones when CUA was being developed. Mice were around and the GUI was very rudimentary (Windows 2.0), certainly when compared to System 4 and 5. In an ideal world, the Meta key, like those found on Sun keyboard, would have been brought over to AT keyboards to cover this.
I can’t stand X11-style copy-on-select/middle-click-paste, and disable that everywhere if that’s what you’re referring to. I habitually highlight text as I read it and hate it when it blows away my existing copy buffer. I want explicit copying, I just don’t want it to collide with SIGTERM.
I think it’s what you’re used to. I’m used to the Mac keyboard (since 1994) and I much prefer the command key for keyboard shortcuts. I can use my thumb all day but pressing control with my pinkie starts to hurt really quickly!
It’s not really an issue for me because I use a Mac. Having said that, I did remap the caps lock key to control which helps a lot. I usually press it with my ring finger.
You can’t, basically. The copy key isn’t configurable for example, you’d need to rewrite the apps from source to achieve this. Some dynamically link to shared library UI toolkits that you could patch, others implement it themselves… it’d be a never-ending game of finding new broken apps and fixing them one by one (and that’s for open source apps, forget closed source ones.)
You could map Cmd to Ctrl but that only fixes copy/paste, but now it will send a SIGTERM to the terminal on Cmd-C now, which means that’s still a pain.
You could write some custom keyboard driver that intelligently maps the command keys to the right keys the app expects, dynamically based on some rules, but that sounds horribly brittle and likely unworkable.
This isn’t new for Sequioa. OS X has been certified by the Open Group for decades now.
Yeah this is misleadingly worded as if this is something new for Apple. They've been officially certified as Unix for 16 years now.
What’s new is a new level?tier? Of the certification that macOS sequoia has been certified for, rather than the overall Unix certification. [0]
[0] https://news.ycombinator.com/item?id=41698775
(According to wikipedia: All versions of macOS from Mac OS X Leopard to macOS 10.15 Catalina, except for OS X Lion,[68] have been registered on Intel-based systems, and all versions from macOS 11 Big Sur, the successor to macOS Catalina, to macOS 14 Sonoma have been registered on both x86-64 and ARM64 systems.)
How is macOS certified as 'Unix' but the modern BSD's aren't? Didn't they all come from the same codebase?
It's not simply that certification costs money. It's that a lot of modern UNIX-like operating systems don't adhere to the UNIX spec. For example, the OpenBSD man pages specify the ways in which they diverge from POSIX and UNIX in the Standards section: https://man.openbsd.org/sh.1#STANDARDS, https://man.openbsd.org/awk.1#STANDARDS. Often times these are small deviations that might not matter to most people, but it means that they aren't UNIX.
Terry Lambert has written about the work he did to make Mac OS X UNIX compliant: https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix...
I don't know how much it costs for the Open Group to certify an OS as UNIX compliant (if anything).
A lot of the time, things are compliant in most of the common stuff, but they might not implement all of UNIX or POSIX. Close isn't compliant, but it's enough that most people don't care. For example, do you care if your Linux disto comes with the `pax` command? Or do you just use `tar`?
Apple had started calling OS X UNIX and was being sued for calling it UNIX when it wasn't actually UNIX. They decided it'd be cheaper to do the work to make OS X UNIX compliant than to deal with the lawsuit and that's what they did. BSDs never cared about calling themselves UNIX so they never went into the nitty gritty of making themselves UNIX compliant.
I agree, though I feel compelled to post that the BSDs learned their lesson about the use of the UNIX trademark the hard way. Part of what caused the classic lawsuit between the Regents of the University of California (the "Berkeley" in Berkeley Software Distribution) and AT&T was the fact that a spinoff company selling BSD had the phone number 1-800-ITS-UNIX:
https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....
This lawsuit happened (1992-1994) when Linux was in its infancy (Linus Torvalds started work on Linux in 1991). Had the future of BSD not been so uncertain during this lawsuit, it is quite possible that some derivative of BSD would be the dominant FOSS operating system today instead of Linux.
Linux's dominance might still have emerged due to the individuals behind it. Beyond Torvalds' work on the kernel, Richard Stallman and others had a significant influence in shaping its early trajectory. Their philosophies and actions were key in driving the open-source movement forward.
The BSD license, while appealing to corporations due to its permissive nature, allows proprietary entities to incorporate the code into their products without giving back to the community. This has happened multiple times, with examples like Apple's Darwin, NetApp, QNAP, and Sony's PlayStation systems.
The GPL, on the other hand, attracted early contributors because it ensured that their work would remain open and shared with the world, rather than being exploited for profit.
They did not come from the same codebase, though that's less relevant in this case.
Apple paid for certification.
certification costs money
Being certified Unix has nothing to do with being based on Unix code either anymore, Huawei paid for their Linux distro based on RHEL (EulerOS) to be certified Unix once.
> Being certified Unix has nothing to with being based on Unix code…
Never has. In very simple terms, it was always about standardizing OS interfaces for variant Unices. Over time, it’s moved on to be aligned with POSIX.
Why is this relevant?
Who is interested about such certification?
Historically, the US Government. NIST mandated that only those operating systems should be used where existing applications can easily be ported to and fro, and POSIX compliant OS-s tick all the boxes. Windows NT got its POSIX subsystem for this reason: https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
Which was hobbled to the point of uselessness are purely a box ticking exercise.
Most cross-platform applications for desktops and servers. If you write to the POSIX standard, it will work on a wide range of systems. Many applications don't need to go beyond that.
Anyone who either develops or requires POSIX (now UNIX) compliant services or tools?
The brown M&M test is: can you call poll() on a terminal device?
This lack of functionality has been in existence since Mac OS X's inception. It's the reason why a cross-platform software _always_ has to support both select() and poll() to check if a user is typing on the terminal -- select() just for Mac OS X, and poll() for every other system. Wouldn't it be nice if we could standardise on poll()?
Compare what macOS manpages say:
https://developer.apple.com/library/archive/documentation/Sy...
> BUGS: The poll() system call currently does not support devices.
with the requirements for certification:
https://pubs.opengroup.org/onlinepubs/9799919799.2024edition...
> The poll() and ppoll() functions shall support regular files, terminal and pseudo-terminal devices, FIFOs, pipes, and sockets.
Is the bug fixed in macOS 15 or is this certification yet another load of horseshit?
Certification aside, Linux and macOS are so similar that I only think about the difference in the rare instances where they differ: three that come to mind are xdg-open vs. open , systemd vs. launchd, and sed -i vs. sed -i ''.
GNU coreutils often have many different options than their BSD counterparts. They both (generally) share a POSIX-specified base wrt options and behavior, but if you commonly only work with one of the two, it's easy to accidentally write non-portable shell scripts.
GNU vs BSD grep is the main one for me. And all the other extremely convenient GNU-isms that I've grown used to in GNU/Linux.
The only GNU-ism I really missed was the `--group-directories-first` option for `ls`
But that was easy enough to fix. ¯\_(ツ)_/¯
For me it's the fact that options cannot come at the end, eg this "rm somedir -r" which I always do (habit) works only with gnu version of cmds.
LXC vs... um... (sigh)...
https://github.com/rust-lang/rust/issues/131374
I've never understood how they keep getting certified when, if I recall correctly, POSIX semaphores are broken on MacOS
I wonder what's the reason for Apple to do this though? Convincing more people to run a macOS server instead of a Linux/BSD one is unlikely the reason (in my mind), but it doesn't make any other sense either...
> I wonder what's the reason for Apple to do this though?
> it was done to get Apple out of a $200M lawsuit filed by The Open Group, for use of the UNIX™ trademark in advertising.
https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix...
Official Unix certification may matter at workplaces and institutions where such certifications are required for meeting some type of compliance criteria. For example, if I remember correctly, early versions of Windows NT had a POSIX compatibility layer, which was crucial for getting Windows NT accepted by some US government agencies.
Still, I hope Apple resurrects their server line… hardware and software. It’d be nice to have a server oriented UNIX running on Apple Silicon without resorting to Linux.
OpenBSD works on Apple silicon, has done for the last few releases.
Cutler must have hated that layer!
Does Apple have renewed server plans on the horizon?
I'm hoping this pushes them to finally implement the glaring gaps in Unix compat: specifically pipe2.
But is pipe2 not Linux specific? It isn’t POSIX, AFAIK.
It originally showed up in Linux, but it's pretty much universal except for MacOS. I mostly hope they start taking the "unix" part of the OS seriously again. It's been almost frozen in time.
This sounds rather dry and abstract. What I would rather like to know is: If I installed Sequoia on my x86_64 Mac, what would I lose in comparison to Ventura? I assume newer OSs increasingly drop x64 support.
Not much
I mean I know for all practical purposes that this really doesn’t mean much, but it means a lot to me; I was a big Sun guy back in the day, and a dash if Irix here and there.
Curious, why does it matter?
Marketing. They called OS X, as it was at the time, ‘UNIX’ but didn’t pay the Open Group for certification. The Open Group sued, and Apple figured it was cheaper to certify, so they did, and have done ever since.
Huh. Does anyone actually care whether or not it's certified? Like is there any business or use case where it would matter?
The Open Group, holders of the Unix trademark care.
my problem with macos is not Unix certification but its keyboard,the odd CMD key messed up with my other ten non Mac keyboards
I love CMD because it’s part of the copy/paste shortcut but not used for any terminal control codes. So there’s no confusion about whether you’re going to accidentally SIGTERM something in the terminal by trying to copy text.
I really really wish I could have this behavior on Linux… but alas, every app under the sun chooses its own copy/paste shortcut and they all use ctrl+C/V by convention so you can’t configure it globally without rewriting every app (ok maybe you could narrow it down to a few GUI libraries like gtk/qt/etc but it’s still a huge undertaking.)
I’d settle for “ctrl-c is copy if text is selected, SIGTERM otherwise” logic, which I think Windows’s console uses, but none of the Linux terminals I’ve tried support that. I’m left with ctrl-shift-C for copy, which leaks into my muscle memory, then I accidentally use that combo in the web browser too and it opens developer tools or something. So annoying.
Copy on selection is ubiquitous in all terminal apps. Shift+insert can be a reliable "paste" shortcut in most places.
Shift+ins is CUA, an actual standard. Which makes far more sense than parroting Microsoft’s decision to use CTRL as a modifier, aping Mac OSs keyboard shortcuts in Windows 3.1.
That’s fine for paste, but copy is the real problem. Also, shift and insert are very very far apart from each other and are not one-handable if you’re holding the mouse with the other hand.
Copy is Ctrl+Ins, cut is Shift+Del. Looking at my ANSI keyboard, all are achievable with one hand. Though, when these were designed, GUI’s on IBM based machines weren’t really a thing and two-handed keyboard shortcuts were common-place.
With a right handed mouse it’s hard to do Ctrl+Ins with my left hand. But it’s possible, I’ll admit. It’s just pretty suboptimal given how ergonomic Cmd+C is on a Mac keyboard (thumb on Cmd is way easier to reach for than pinky on ctrl, and reaching for ctrl+Ins is harder than either.)
Yeah, mice weren’t really a thing on the early IBM AT’s and clones when CUA was being developed. Mice were around and the GUI was very rudimentary (Windows 2.0), certainly when compared to System 4 and 5. In an ideal world, the Meta key, like those found on Sun keyboard, would have been brought over to AT keyboards to cover this.
TIL https://en.wikipedia.org/wiki/IBM_Common_User_Access
I can’t stand X11-style copy-on-select/middle-click-paste, and disable that everywhere if that’s what you’re referring to. I habitually highlight text as I read it and hate it when it blows away my existing copy buffer. I want explicit copying, I just don’t want it to collide with SIGTERM.
I think it’s what you’re used to. I’m used to the Mac keyboard (since 1994) and I much prefer the command key for keyboard shortcuts. I can use my thumb all day but pressing control with my pinkie starts to hurt really quickly!
Press Ctrl with a side of your palm, I've been doing that for years after a brief stint with emacs, no problems with the finger.
Also, on decent keyboards (not necessarily expensive) you can remap the keys anyway.
It’s not really an issue for me because I use a Mac. Having said that, I did remap the caps lock key to control which helps a lot. I usually press it with my ring finger.
I need to find a guide on how to get the Mac keyboard experience on Linux. I agree that it’s objectively better.
You can’t, basically. The copy key isn’t configurable for example, you’d need to rewrite the apps from source to achieve this. Some dynamically link to shared library UI toolkits that you could patch, others implement it themselves… it’d be a never-ending game of finding new broken apps and fixing them one by one (and that’s for open source apps, forget closed source ones.)
You could map Cmd to Ctrl but that only fixes copy/paste, but now it will send a SIGTERM to the terminal on Cmd-C now, which means that’s still a pain.
You could write some custom keyboard driver that intelligently maps the command keys to the right keys the app expects, dynamically based on some rules, but that sounds horribly brittle and likely unworkable.
:(
I agree. I really like the ALT shortcuts on Haiku, and I remap my external keyboard on macOS so command is mapped to ALT rather than Super.
I’ve used MacOS with an old IBM model M for 20 years… I map the caps lock key to CMD, as I dislike and never use caps lock.