Macos Tahoe Is Certified Unix 03 [pdf]
Posted4 months agoActive4 months ago
opengroup.orgTechstoryHigh profile
calmmixed
Debate
60/100
Unix CertificationMacosPosix Standards
Key topics
Unix Certification
Macos
Posix Standards
The news that macOS Tahoe is certified Unix 03 sparks a discussion about the significance and implications of Unix certification, as well as the history and future of POSIX standards.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
1h
Peak period
89
0-6h
Avg / period
22.9
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Sep 14, 2025 at 7:01 AM EDT
4 months ago
Step 01 - 02First comment
Sep 14, 2025 at 8:25 AM EDT
1h after posting
Step 02 - 03Peak activity
89 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 16, 2025 at 11:43 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45238930Type: storyLast synced: 11/20/2025, 7:55:16 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
So, for all intents and purposes, nothing that would be relevant in any reasonable end-user way in 2025. It’s all just: here’s defaults and here’s scripts to set up your environment and here’s a dozen things to run brew with. But no standard.
And some simple command for any Linux distro or macOS to install everything necessary to adhere to that standard, or a distro that conforms with that standard in the first place.
https://pubs.opengroup.org/onlinepubs/9799919799/idx/utiliti...
https://en.wikipedia.org/wiki/Single_UNIX_Specification#Comp...
It's basically the only relevance the Unix trademark has these days. I can't imagine many companies choosing macOS because it's a real Unix, nor would anyone really opt out of z/OS, AIX og HPUX, if they where not certified.
Am I missing something? I’m not sure why it’s coming off like people are complaining about this?
[1]: https://news.ycombinator.com/item?id=45239534
I don’t know what to tell you. Pick your theory:
A) apple does it for no reason and it is a waste of money B) they do it because they are aware or benefits that outweighs the small certification cost
I guess it's just, might as well keep it going, as an option for future marketing if ever needed. Maybe it helps the salespeople in some enterprise deals? I mean, if it doesn't really cost anything to keep it.
NeXTSTEP had to support UNIX, because that was the workstation market they were after.
However notice how everything relevant for NeXT products was based on Objective-C userspace tooling and frameworks.
Also, Apple is a huge company, there's the question of who's going to make the call the not update a certification that's negligible within the scope of macOS development. Better to not be that person and just rubberstamp the invoice from The Open Group. If management disagree, they can make the call, but they won't because the cost is to small for them to deal with.
> there's the question of who's going to make the call the not update a certification that's negligible within the scope of macOS development.
And one way that's managed is to have a DRI system which (ideally) prevents this from happening.
Does anyone want to be the person that removes regression tests from active use, only to be responsible when something breaks that would have been caught by that test? Far easier to just fix your code so the test passes.
(And for many years, OS X then macOS had a reputation for being rock-solid, capable of going much longer betwen restarts, going into BSOD much less frequently than Windows would. Having a set of third-party tests certainly didn't hurt this!)
While Unix compliancy isn't what's keeping me on macOS, the Unix tools it has under the hood still is. I've opted to use it over Linux because I still get everything that I need from a "Unix like" standpoint while having some serious enterprise level support and compatibility with work software that's often only available for windows or Mac.
If Apple stopped caring about being Unix compliant, I wouldn't be surprised to see the tools and infrastructure that make it Unix (and useful to me) slowly be removed. Then I'd stop using it.
In some ways, Apple's adherence to UNIX specifications probably makes macOS less useful for you. For example, I wish that grep on macOS was closer to GNU grep. When I look up commands online, I often find answers based on the GNU implementations. Those often work on macOS, but sometimes don't (or have subtly different behavior) because macOS is adhering to the UNIX specification rather than to what those utilities do on the vast majority of systems out there.
I don't think Apple would be removing UNIX-like tools from macOS even without certification. They know how valuable it is that most developers use their systems. Even Microsoft went so far as to implement the Windows Subsystem for Linux for developers. At this point, I think that UNIX certification makes macOS less compatible with the tools and help out there which generally targets Linux. Usually the differences are small, but they certainly can be meaningful.
I certainly replace a large chunk of the "unix tools under the hood" with tools installed via homebrew.
Isn’t it rather that Darwin was based on BSD 4.4? I’d imagine GPL 3.0 is a bigger impediment to them ever migrating to GNU tools than any desire to be UNIX certified.
It derives from 4.4 BSD but it's more than that.
macOS includes a woefully outdated bash 3.2 due to GPL 3.0; they switched to zsh long ago.
Even if macOS wasn’t UNIX-certified, Apple would still be unwilling/unable to include the GNU software due to the license. I can’t see the Apple of today implementing a full suite of non-GNU software but with GNU-style options either.
So, POSIX compliant or not, there’s probably no world where `grep -P` works out of the box on a Mac.
There's no reason to include GNU anywhere. I don't know why Apple would.
I hope you're right but I'm not as confident. Corporations - Apple included - have been guilty of some surprising ignorance when it comes to things like this. I'm thankful for this certification circus to continue so that we don't need to test your theory.
Afaik, EulerOS and other Unix-certified Linux distros just ship the usual GNU userland.
It's not just about going through a song-and-dance. It's about making an OS that has different behavior - often very tiny differences, but differences that would make the distro worse for most users.
Is this actually true? Can you give a real example of where Huawei EulerOS or Inspur K-UX are inferior to their non-certified base (yet another Red Hat Enterprise Linux clone) due to their UNIX certification?
I wouldn't be surprised if there were still patches required, but at least on the face of it that should get you most of the way there.
UNIX certification is not the reason why macOS utilities are missing options compared to GNU - UNIX standards say you have to have certain options which work a certain way, they don’t prohibit adding additional options as vendor extensions. The reason is that Apple’s investment in improving these tools is minimal because it is a low priority for them, and because people who get annoyed by this often just end up installing the GNU tools anyway (using Homebrew or MacPorts)
In fact, GNU/Linux systems have been certified as UNIX in the past, by a couple of different Chinese vendors (Inspur K-UX, Huawei EulerOS)-which shows use of the GNU tools is no inherent obstacle to certification. The reason these vendors stopped, I suspect, is the money it was making them was smaller than the certification costs and UNIX trademark license fee
To get UNIX certification, you can just patch it to make POSIXLY_CORRECT=1 the default.
Or even don’t patch the utilities, and just patch /etc/profile to set POSIXLY_CORRECT=1 globally.
UNIX certification requires that the system have a mode of operation available which passes the test suite; the existence of config settings which if changed from their defaults produce standards violations is not in itself a standards violation.
Outside of coreutils, let's consider bash and ksh88.
The two have differing behavior in several areas (coprocesses, alias handling, final pipeline fork, etc.), but this divergence in behavior happened before POSIX.2 and the standardization of the POSIX shell, which is largely a subset of ksh88.
The gist is that activating a mode for POSIX compliance will generally remove functionality, because the standardization happened a decade after development began, and the standards themselves were excessively conservative in adherence to System V.
I've seen that useful GNU extensions are generally adopted by BSD, but much more slowly by POSIX.
That does not serve UNIX well. Someone should challenge the Austin Group for effective control of UNIX standardization.
Anyway, I think this is somewhat a non-issue: even if bash doesn't fully comply with POSIX standards by default, it should still be possible to be POSIX compliant by delivering a compliant shell in the right place. Though this does make me wonder if there's anything in POSIX that would require the user's default login shell to be POSIX-compliant, Bourne shell compatible. Probably not, right? After all, macOS had been using bash for ages with no issues complying.
You can see this in a script by defining:
Then try to use it with bash. If bash is running as #!/bin/sh, then it will work, because bash is forced into POSIX mode.However, if the script is running as #!/bin/bash, then you will be in the '80s behavior, and it will fail.
Try it.
macOS still has a bunch of GNU tools, but they appear to be incompatible with GNU tools used everywhere else, because they're so outdated.
The problem with the old tools is that I don't have admin rights at work so it's not easy to install coreutils. Or even homebrew.
I can understand why they did it though. Too many tools these days advocate just piping some curl into a root shell which is pretty insane. Homebrew does this too.
I don't remember all the specifics but every time there was a new macos I could cross most of the new features off. Nope this one requires iCloud or an apple ID. Nope this one only works with other macs or iPhones. Stuff like that. The Mac didn't use to be a walled garden. You can still go outside of their ecosystem (unlike on iOS) but then there's not much point. You're putting a square peg in a round hole.
Now, Apple isn't the only one doing this. Microsoft is making it ever harder to use windows without a Microsoft account. That's why I'm gravitating more and more to foss OSes. But there are new problems now, like with Firefox on Linux I constantly get captcha'd. M365 (work) blocks random features or keeps signing me out. My bank complains my system is not 'trusted'. Euh what about trusting your actual customers instead of a mega corp? I don't want my data locked in or monitored by a commercial party.
Right, but I think GP's point is that if Apple didn't feel pressured to get macOS UNIX-certified, then they wouldn't even bother to be UNIX-like. That is, all sorts of UNIX-required command-line tools would start to disappear from the default install, and things like POSIX conformance would take a back-burner, etc.
Not sure if I agree with that, but that's what GP seems to be suggesting.
> For example, I wish that grep on macOS was closer to GNU grep.
This has nothing to do with UNIX conformance; this just comes from macOS's BSD background, which does not use the GNU core utils. If the Linux folks wanted to go through UNIX conformance testing, they wouldn't have to switch away from GNU tools. And macOS could swap out the BSD-sourced tools for GNU tools and still get their UNIX certification.
> I have to learn the replacement from ifconfig
MacOs switched to networksetup and ipconfig a long time ago. Ifconfig is not recommended so the situation is exactly the same than on Linux here.
> launchd IMHO is way better than init.d and systemd
Systemd is basically a more complete and better designed launchd. Having used both I have trouble thinking of anything launchd does better.
> the command line diskutil and other additions still feel like its more Unix like
Diskutil is a MacOS only tool. I’m a bit lost about what your argument is here.
Linux still use fdisk and dedicated tools to create file systems exactly like on FreeBSD or any other Unix. It’s MacOs doing its own thing here.
All that being said, I've spent some time on Arch, and I really like pacman and the AUR setup. And all that documentation is just amazing. I really didn't understand systemd before I read the archwiki article on it.
SystemD I think was a bit inspired by Launchd.
Everything except a package manager!
I'm convinced the devs inside Apple know what I'm saying as well, and are giving as much help as possible to Homebrew to keep it independent. There is some small proof, Homebrew was considered very highly during the DTK rollout for Apple Silicon.
Those that have one, it is not standard.
The Unix don’t really share much between each other apart from a small core.
One is better using the Windows alternatives.
Speed bumps regarding what?
I’m mostly using Linux nowadays but when I have to use Windows, the experience is fairly ok. The tooling when you want to manage it is imho superior to what Apple provides. I’m not used to develop on it but I have seen people do and it didn’t seem particularly worse than Linux-like environment.
Not that I really have anything against MacOS. I think it’s neglected by Apple and not as enjoyable as it used to be. I dislike Apple and the policies it’s pushing for. Nevertheless, it’s ok to use. Everything pretty much is nowadays.
Speed bumps regarding compilation of tooling written with UNIX semantics in mind, without taking into consideration Windows development culture and OS semantics.
Linking to Glibc? Sharing a roughly similar file system structure? Expecting bash to be there?
Because from where I stand the people that care about BSD have spent the past decade complaining it’s getting more and more complicated to port Linux software so I’m very curious to know what the common DNA is supposed to be.
I get that you meant is probably that MacOS is close enough to Linux that you can somehow pretend it is the same when developing things which are ultimately going to run on Linux.
To which I say, I personally think that buying Apple is wasting a lot of money for something which would work fine in a VM but well, that’s nice aluminium I guess.
macOS, Linux, and BSD treat CMD and GUI applications the same while Windows separates applications. Window's two type of application approach brakes the ability to use STDIN and STDOUT for logging and other useful means. Simple debugging of `./app > app.log` does not work on Windows with `app.exe > app.log` with GUI applications. The Windows variant needs a specialized logging system and more boilerplate code.
Windows also has one of the worst automation system when it comes to solution deployment. One needs to create custom mouse and keyboard emulation scripts to automate the installation of 3rd party applications when their installer does not support silent mode. AutoIT helps me with this greatly.
But Windows also has strong automation tooling: PowerShell, WinRM, Chocolatey, Winget, MSIX packaging. These provide far more than “mouse and keyboard emulation.”
So your statement ignores the modern ecosystem and overstates the weakness.
Also the PowerShell is actually broken. I can use standard network powershell commands that brake the OS applied to network interfaces. Currently waiting on a laptop with bare metal Windows installation to verify if those sanitized PowerShell commands are crashing the VM or Windows itself.
.NET for the longest time was broken with _NetworkInterface.GetAllNetworkInterfaces()_ only returning enabled NICs. This was finally fixed in .NET 9. Work around his to go WIN32 custom coding when older .NET must be used.
.NET WPF touch screen event messaging system is also broken where it would latch depending on how the finger is swiped off a button. Had to dump that and go with WIN32 as work around so that bug didn't have the capability to crush someone's appendage when being used in machinery.
The registry system the OS is built upon is flawed. It does not have well defined layout such as a configuration file.
Hard to tell with a config file.
It's what, 6 different versions of Windows, with quite clearly defined API "eras"? For Linux, you have just a huge ball of mud^H^H^H distros each of which has (or doesn't have) who knows versions of what, but of course, there you can just give out a .tgz with source code and say to your users "it's your problem now to build it for yourself since you're using Arch".
The thing I hated the most was spending time building installation scripts or running images for the prod environment, and then go fight macos to replicate the same setup locally. Especially having parralel installs for the system and my user account was a PITA.
One would argue I could just dev on the docker image as well, but then being on a somewhat unixy OS doesn't matter much anymore.
WSL let's the Windows side live it's life (shell level tools can still be injected for convenience), and the linux side be genuinely Linux, not some ersatz, and duplicable to one's heart content. It's still less pain and better perfs than straight docker, and just extremely well integrated in general.
http://xahlee.info/UnixResource_dir/apple_unix_ad.html
POSIX conformance is a cherry on top, and it helps get them certain sales that require a conforming Unix. But that's not the real value to the platform.
For example, Apple federated accounts are a great idea. But, in your global directory the UPN and email must be the same. For us it's not, with good reason. We're not going to change our entire setup globally to suit Mac users that make up 0.5% of our systems. And there's never going to be more unless they become more accommodating. We even looked at JAMF but it's too much work to implement a whole separate management system. And the options in apple's configuration profiles are way too limited.
Another issue, every account that has already been created as a private Apple id on the corporate email must be manually resolved. Impossible with many tens of thousands of users.
AD binding while rudimentarily supported, causes so many issues. If someone's password expires there's no way to log in unless they're physically on the company network. The problem is that our security team demand we bind to AD. Not Azure AD. That's just reality in enterprise.
Having a managed local admin account is also a really big problem and there isn't really any tooling for that.
Maybe if you go all in on Apple like IBM did, then yeah you could adapt your environment to all their quirks. But it's a big blocker for small deployments. And really besides IBM nobody in enterprise did this. Apple meanwhile doesn't really care anyway. They only care about the customer market.
So that target audience gets a cool modern experience, without fighting with driver issues and such.
It is also the reason why Microsoft ended up bringing Project Astoria from the ashes into WSL.
UNIX has won, but not as Richard Stallman would have liked to.
Me, I live in the real world and got dotfiles to clone.
Git is not a GNU project and is GPL v2.
Install everything XCode and use proper UNIX tools already installed.
Fwiw, though, I personally do use a ton of GNU software on any Mac I touch: coreutils, grep, sed, find, parallel, GCC, autotools, make, gdb, Emacs, and maybe some GNU Java stuff for LibreOffice, Bash. Most developers on macOS probably use at least a couple of those.
> Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt.
-- https://www.gnu.org/gnu/manifesto.html
However Aix, Solaris (and Open Solaris derivatives), z/OS, IBM i (AS/400), ClearPath MCP, OS 2200, are still being updated and sold.
That list is not only UNIX systems.
Can I call poll(2) on a terminal device's file descriptor?
Requirement 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.
Apple (last time I checked): https://developer.apple.com/library/archive/documentation/Sy...
> BUGS: The poll() system call currently does not support devices.
I asked the same question of Sequoia: https://news.ycombinator.com/item?id=41822308
Meanwhile poll() just works on Linux and the BSDs, certified or not.
> 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.
Except it seems like macOS diverges, too, yet it is certified. I wonder in what other ways it diverges.
https://www.opengroup.org/openbrand/register/brand3617.htm
https://www.opengroup.org/openbrand/register/brand3622.htm
Save these links for the next time someone moans that Linux "is not a real Unix".
In order to get a Linux distro certified, you'd have to make changes which would make it less compatible with all the other Linux distros out there.
The reason why RedHat doesn't pay for UNIX certification is that their distros wouldn't be compliant. The reason why they don't make their distros compliant is that their customers would vastly prefer that RedHat use "standard Linux" tools than replace them with UNIX-compliant ones. Customers don't want a Linux distro that's subtly different/incompatible compared to what everyone expects in a Linux system. They'd rather it be not-UNIX.
Yes, you can modify a Linux distro to be UNIX. However, most Linux systems are not real UNIX - and you wouldn't want it to be real UNIX.
the GNU userland might be common for user facing systems, but it's nowhere close to standard.
If you are going there, I also consider Kubernetes optional.
When I have the option to push for specific cloud deployments, I usually push for serverless or managed containers.
You might argue that still depends on Kubernetes, for me Kubernetes just like Linux, is mostly an implementation detail, that we get to open support tickets when it doesn't go as planned.
No one needs to hurt themselves running a local Kubernetes cluster.
I'm not sure what you mean by "Unix specification". But if you mean the international standard POSIX, yes, people care. Red Hat routinely participates in POSIX spec revision.
There are a very few deviations where you have to enable "POSIXLY_CORRECT". If that's what you mean, then you can turn that on. But in every area that matters, Linux distros implement the POSIX spec by default, and you can even turn on the POSIXLY_CORRECT mode to exactly follow it. They extend beyond it, but that is allowed and expected.
The people who build the tools in Linux distros care a lot. I know the implementors of dash and GNU make routinely refer to POSIX. The Linux distros don't have to as much with POSIX because that is generally a conpleted work and it's the maintainers of the tools who must address the updates to POSIX.
You might say "their exact view of what UNIX is isn't important and POSIX is," but POSIX is not the UNIX spec. You might think the Unix spec isn't important - and it really isn't today. Linux generally targets what is important and what users care about - and that isn't the UNIX spec. It is often the same as the UNIX spec, but not always and there are deviations.
> I was asked if I could lead a team to do #1. I said “Yes, under the condition that I could use the compliance project as a hammer to force other parts of the organization to make changes in their own code base, and that I could play it rather loose with commit rules regarding what it said in the bugs database for a given code change, and what the given code change actually did, in addition to what it said in the bugs database”.
…
> We were promised 1/10th of the $200 million, or $20 million in stock, on completion. $10 million to me, $5 million to Ed, and $5 million to Karen Crippes, who was looking for a home in Mac OS X development, I knew was an amazing engineer, and who could be roped into being technical liaison and periodically kicking off the tests and complaining to Ed and I about things not passing.
—-
Source: https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix...
HN discussion: https://news.ycombinator.com/item?id=29984016
Guess it shows that when it comes to compensation promises always get it in writing.
Sorry, I’m probably missing the obvious.
“The executive who agreed to the deal left his wife for an HR person, and took the stock for himself.
Never every make a handshake deal with a person you trust, because that trust will not last.”
If they balk, it's precisely because they want to be able to be free to cheat you out of it once the work is done.
> Also, the tech lead has to fix anything no one else fixes, or no one else can fix, because they are the DRI (Directly Responsible Individual).
How many tech lead/project manager can say that they are capable for this in these days? It feels like based on my observations that other skills are taking priority on management/lead side.
34 more comments available on Hacker News