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

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.

It is also relevant, that as proven on FOSDEM corridors full of Apple laptops, most folks only care about some sort of POSIX experience, and couldn't care less about Linux/BSD religion.

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.

That explains why they got it UNIX certified back then, but couldn't they stop advertising macOS as UNIX and stop getting it certified? They even changed the name from Mac OS X to macOS since then.

Literally the only reason that kept me on the platform until recently despite becoming increasingly hostile to developers...

You forgot solarius, well, so did oracle.

Used to work with UNIX servers in the early 2000s but out of that sector for coming up on two decades -- are z/OS, AIX and HPUX (and other old big iron enterprisey UNIXen) still around? I would have thought that Linux had killed them all of by now. Excuse my ignorance!

And if you read further in the comments, he never got the stock. The executive who promised it to him “took it for himself.”

Further below:

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

Thank you for sharing, what an interesting read.

It's not just about paying for certification. You also have to replace a lot of things like ed, awk, grep, etc. with versions that are compatible with the UNIX specification. GNU utilities didn't target 100% UNIX compatibility and they have differences that mean that a command that works on UNIX might not work (or might not work the same) on a Linux distro using GNU utilities. glibc has slight differences from the spec too.

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.

Thanks for the link, that's a good read.

the big difference is that the Linux + GNU standard is not controlled by a corporation whose only motive is profit, and that the reference implementation is Free Software that everyone can potentially contribute to.

i would not call that a regression. compare that to the browser standard which is largely controlled by google.

The best “standards” just ratify what people are already doing.

And someone said:

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

I had to work around this recently - it involved reimplementing my poll wrapper on top of select(), with the proprietary macOS extension that makes it support unlimited fds. (Of course -D_DARWIN_UNLIMITED_SELECT is completely unportable, so I still need poll too.)

Meanwhile poll() just works on Linux and the BSDs, certified or not.

Note: while the link above points to a newer standard, the quote has already been present in the one for UNIX 03 it seems: < https://pubs.opengroup.org/onlinepubs/009696699/functions/po...>

I don't think it's that surprising that the Open Group would cut corners certifying Unix compatibility.

I came here to mention this too, but saw you'd beaten me to it. It's remarkable how bad non-free OSes are at maintaining basic infrastructure in their kernel and userspace compared to Linux and the BSDs isn't it? Basic bugs get neglected for decades in favour of rearranging the cosmetics - in this case, it's been more than 20 years since I first reported this to Apple's /dev/null service, and I'm sure I wasn't first and I'm only one of many.

Also, the weird `fsync` behaviors is not part of it?

No, and that's a good thing. Just look at how quickly features are added to the living browser standards. Instead, we get a new POSIX version every couple of years that includes the special cases that actually work the same on BSDs and Linux after they're already implemented.

There's pthread_cond_timedwait_relative_np. Looking at the implementation, pthread_cond_timedwait starts by converting the deadline to a relative timeout [1], but this is skipped if pthread_cond_timedwait_relative_np is used. Then, in the kernel, the timeout is converted back to an absolute deadline by either [2] or [3], but both of those are using Mach absolute time rather than the wall clock.

Mach absolute time is monotonic. It pauses while the system is asleep, which may or may not be what you want.

If need the timer to keep incrementing while the system is asleep, there's no way to do it directly with a timed wait, but you can use kevent with EVFILT_TIMER + NOTE_MACHTIME + NOTE_MACH_CONTINUOUS_TIME.

[1] https://github.com/apple-oss-distributions/libpthread/blob/1...

[2] https://github.com/apple-oss-distributions/libpthread/blob/1...

[3] https://github.com/apple-oss-distributions/xnu/blob/e3723e1f...

I don't know about the Unix certification process itself, but the Single Unix Specification explicitly mentions case-insensitivity among non-conforming file system behaviors that are allowed as extensions (in 2.1.1 item 4, third-to-last bullet):

https://pubs.opengroup.org/onlinepubs/9799919799/

So a conforming OS has to make case-sensitive file systems available (which MacOS does: you can create case-sensitive HFS or APFS volumes). But I'm not sure if a conforming OS instance (i.e., running system) has to have any case-sensitive mount points, and either way, AFAIK there's no practical and race-free way for a conforming application to detect whether any particular mount point behaves case-sensitively.

So I believe that as far as the standard goes, a conforming application might run on a conformingly-extended OS where no portion of the the file namespace behaves case-sensitively. IOW, a conforming application cannot rely on case-sensitivity for file names.

There’s a specific “Unix mode” you have to turn on to be in the compliant state, it’s not the default. Presumably among other changes this puts APFS into case-sensitive mode.

I may have mentioned on occasion, here or there, about how ludicrous it is that there appears to be no well-defined standard that user space shall have sqlite3 and git and gzip.

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.

Yes, there is "UNIX V7" in 2013... which apparently only IBM's AIX supports. This is ironic because the whole idea of UNIX is to create a common platform for interoperability, but only one platform actually supports. I really wonder why Apple just doesn't put a couple of FTEs on it and upgrade to V7. I'm sure it wouldn't take much. But it sort of reminds me of Java and HTML where there were standards to allow for independent implementations, but have collapsed to single implementations.

https://en.wikipedia.org/wiki/Single_UNIX_Specification#Comp...

Grandma doesn't use certified UNIX. She uses a UNIX-like system. Only the engineers who ran the conformance test use certified UNIX since it required what I would consider heavy modification to the shipped OS configuration.

> The year of the linux desktop folks have been trying this for decades.

Have they? I'm not aware that any of the desktop linux projects particularly care about POSIX or being a certified Unix™.

Sounds good, but grandma will need to disable SIP, run a few commands using sudo, and add a root account from the recovery system. It's Unix in the same way Windows 2000 was POSIX compliant, you just need to reconfigure the default system.

The Linux desktop is widely used all across the world in the form of ChromeOS and, if you count touch screen devices, Android.

my grandma used linux. in 1995!