As an online discussion grows longer, the probability of a someone mentioning macOS is a UNIX approaches 1. In fact, it was only late last year that The Open Group announced that macOS 15.0 was, once again, certified as UNIX, continuing Apple’s long-standing tradition of certifying macOS releases as “real” UNIX®. What does any of this actually, mean, though? Well, it turns out that if you actually dive into Apple’s conformance statements for macOS’ UNIX certification, it doesn’t really mean anything at all.
First and foremost, we have to understand what UNIX certification really means. In order to be allowed to use the UNIX trademark, your operating system needs to comply with the Single UNIX Specification (SUS), which specifies programming interfaces for C, a command-line shell, and user commands, more or less identical to POSIX, as well as the X/Open Curses specification. The latest version is SUS version 4, originally published in 2008, with amendments published in 2013 and 2016, which were rolled up into version 4 in 2018. The various versions of the SUS that exist, in turn, correspond to a specific UNIX trademark. In table form:
Trademark | SUS version | SUS published in: | SUS last amended in: |
UNIX® 93 | n.a. | n.a. | n.a. |
UNIX® 95 | Version 1 | 1994 | n.a. |
UNIX® 98 | Version 2 | 1997 | n.a. |
UNIX® 03 | Version 3 | 2002 | 2004 |
UNIX® V7 | Version 4 | 2008 | 2016 (2018 for roll-up) |
When you read that macOS is a certified UNIX, which of these versions and trademarks do you assume macOS complies with? You’d assume they would just target the latest trademark and SUS version, right? This would allow macOS to carry the UNIX® V7 trademark, because they would conform to version 4 of the SUS, which dates to 2016. The real answer is that macOS 15.0 only conforms to version 3 of the SUS, which dates all the way back to the ancient times of 2004, and as such, macOS is only UNIX® 03 (on both Intel and ARM). However, you can argue this is just semantics, since it’s not like UNIX and POSIX are very inclined to change.
So now, like the UNIX nerd that you are, you want to see all this for yourself. You use macOS, safe in the knowledge that unlike those peasants using Linux or one of the BSDs, you’re using a real UNIX®. So you can just download all the tests suites (if you can afford them, but that’s a whole different can of worms) and run them, replicating Apple’s compliance testing, seeing for yourself, on your own macOS 15 installation, that macOS 15 is a real UNIX®, right? Well, no, you can’t, because the version of macOS 15 Apple certifies is not the version that’s running on everyone’s supported Macs.
To gain its much-vaunted UNIX certification for macOS, Apple cheats. A lot.
The various documents Apple needs to submit to The Open Group as part of the UNIX certification process are freely available, and mostly it’s a lot of very technical questions about various very specific aspects of macOS’ UNIX and POSIX compliance few of us would be able to corroborate without extensive research and in-depth knowledge of macOS, UNIX, and POSIX. However, at the end of every one of these Conformance Statements, there’s a text field where the applicant can write down “additional, explanatory material that was provided by the vendor”, and it’s in these appendices where we can see just how much Apple has to cheat to ensure macOS passes the various UNIX® 03 certification tests.
In the first of these four documents, Internationalised System Calls and Libraries Extended V3, Apple’s “additional, explanatory material” reads as follows:
Question 27: By default, core file generation is not enabled. To enable core file generation, you can issue this command:
sudo launchctl limit core unlimited
Testing Environment Addendum: macOS version 15.0 Sequoia, like previous versions, includes an additional security mechanism known as System Integrity Protection (SIP). This security policy applies to every running process, including privileged code and code that runs out of the sandbox. The policy extends additional protections to components on disk and at run-time, only allowing system binaries to be modified by the system installer and software updates. Code injection and runtime attachments to system binaries are no longer permitted.
To run the VSX conformance test suite we first disable SIP as follows:
– Shut down the system.
– Press and hold the power button. Keep holding it while you see the Apple logo and the message “Continue holding for startup options”
– Release the power button when you see “Loading startup options”
– Choose “Options” and click “Continue”
– Select an administrator account and enter its password.
– From the Utilities menu in the Menu Bar, select Terminal.
– At the prompt, issue the following command: “csrutil disable”
– You should see a message that SIP is disabled. From the Apple menu, select “Restart”.By default, macOS coalesces timeouts that are scheduled to occur within 5 seconds of each other. This can randomly cause some sleep calls to sleep for different times than requested (which affects tests of file access times) so we disable this coalescing when testing. To disable timeout coalescing issue this command:
sudo sysctl -w kern.timer.coalescing_enabled=0
By default there is no root user. We enable the root user for testing using the following series of steps:
↫ Apple’s appendix to Internationalised System Calls and Libraries Extended V3
– Launch the Directory Utility by pressing Command and Space, and then typing “Directory Utility”
– Click the Lock icon in Directory Utility and authenticate by entering an Administrator username and password.
– From the Menu Bar in Directory Utility:
– Choose Edit -> Enable Root User. Then enter a password for the root user, and confirm it.
– Note: If you choose, you can later Disable Root User via the same menu.
The second conformance statement, Commands and Utilities V4, has another appendix, and it’s a real doozy (the […] indicate repeat remarks from the previous appendix; I’ve removed them for brevity):
Testing Environment Addendum:
- […]
- By default, the APFS file system updates a file’s atime lazily. To run the Conformance Test Suites, or more generally to get UNIX Standard atime behavior, mount the test partitions (including /System/Volumes/Data) with the “strictatime” option: mount -o strictatime
- APFS file systems can be formatted as either case-sensitive or case-insensitive. Always format as case-sensitive for UNIX Conformant behavior.
- macOS has a file indexing service, Spotlight, that runs in the background and may affect file access times. For UNIX Conformance Testing we disable Spotlight. You can do that with this command: sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
Spotlight can be re-enabled with:
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist↫ Apple’s appendix to Commands and Utilities V4
- […]
- […]
- In macOS Sequoia the root volume is authenticated and immutable. Because of this, and because of the way that you have to configure uucp, you should take the following steps before using uucp (and we do these before running the uu* tests):
- Copy the following binaries from /usr/bin to /usr/local/bin
uucp
uuname
uustat
uux- Copy the following binaries from /usr/sbin to /usr/local/bin:
uucico
uuxqt- In /usr/local/bin, turn on the setuid bit for these binaries:
sudo chmod +s /usr/local/bin/uu*
(This is the step that you cannot perform within /usr/bin or /usr/sbin)- Add /usr/local/bin to your PATH preceding /usr/bin and /usr/sbin
- Enable the uucp service:
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.uucp.plist
The third and fourth conformance statements have no appendix.
Interestingly enough, on top of the appendices, Apple also has four “Temporary Waivers“. These are waivers granted at the sole discretion of The Open Group for a “limited number of implementation errors” that are “demonstrated to be of a minor nature, with negligible impact on interoperability or portability”. These are valid for 12 months, after which the applicant must have removed the errors from its product. These waivers, and its resolutions, must be made public, but I think they’re only made public to registered, paying customers – so I can’t download them to take a look at them. I honestly doubt these are particularly interesting, but I figured I’d mention it anyway.
So, if you want your installation of macOS 15.0 to pass the UNIX® 03 certification test suites, you need to disable System Integrity Protection, enable the root account, enable core file generation, disable timeout coalescing, mount any APFS partitions with the strictatime
option, format your APFS partitions case-sensitive (by default, APFS is case-insensitive, so you’ll need to reinstall), disable Spotlight, copy the binaries uucp, uuname, uustat, and uux from /usr/bin
to /usr/local/bin
and the binaries uucico and uuxqt from /usr/sbin
to /usr/local/bin
, set the setuid bit on all of these binaries, add /usr/local/bin
to your PATH before /usr/bin
and /usr/sbin
, enable the uucp service, and handle the mystery issues listed in the four Temporary Waivers.
Then, and only then, is your macOS 15.0 actually UNIX® 03-certified.
This is batshit insane. I can guarantee you with 100% certainly not a single macOS installation in the entire history of macOS – let alone when just counting macOS 15.0 – has implemented even half of these changes. I’m sure there is a small number of people who have System Integrity Protection disabled permanently, and an even smaller number of people who have enabled the root account, and an even smaller number of people who have done both of those things – but that’s it. All the other changes are far too obscure and specific to be of any use to anyone.
For fairness’ sake, I also took a look at the Conformance Statements for some of the other UNIX-certified operating systems. The only operating system and version that is UNIX® V7-certified is IBM’s AIX 7.2 TL5 (or later), and it has just one note from IBM, containing a single change you need to apply to AIX 7.2 TL5 pass the UNIX® V7 certification process:
Full response to Question 28: The AIX default socket listen queue length is 1024, the maximum is 32767, the value must be modified by using the “no -o somaxconn=5” command to set UNIX03 conforming length of 5.
↫ IBM’s appendix to Internationalised System Calls and Libraries Extended V4
Looking at one of the other UNIX® 03-certified operating systems, there’s HP-UX 11.31 for Itanium, which does have some remarks in its appendices, but they’re informative, and don’t specify any changes that need to be applied to HP-UX to make it pass UNIX® 03 certification testing. For Solaris, there’s a ton of remarks about the differences between Solaris for x86 and Solaris for SPARC, including differences between the 32bit and 64bit variants of those architectures, but that’s it for Solaris. AIX, HP-UX, and Solaris do not require any meaningful changes to pass UNIX certification testing.
I can only conclude that macOS 15.0’s UNIX® 03-certification is a lie. If you need to implement this many drastic changes to your operating system to make it pass the UNIX® 03-certification tests, you’re really not UNIX® 03-compliant. Let me be very clear that this is not some sort of “gotcha!”, scandal, or “-gate”; UNIX-certification for macOS is not some sort of diabolical marketing scheme devised by C-level executives at Apple, trying to lure unsuspecting customers into buying Macs because they’re UNIX-certified. I doubt Tim Cook even knows who on earth The Open Group are. The cold and harsh truth is that literally nobody but a few nerds like us care about this, and even then the level of care we display is minute.
I do think, however, that this puts some serious question marks around just how valuable the UNIX trademark really is, and what it really means for an operating system to be UNIX-certified. If macOS can be a “real” UNIX when literally not a single macOS installation in the world can even pass the certification tests to begin with, what are we really doing here?
This makes one wonder why Apple is allowed to list this many onerous caveats and still be granted the right to use the UNIX® 03 trademark, and I honestly have no idea. The Open Group and its certifications do have an air of pay-to-play, but Apple is only a silver member, which costs a measly $22000 per year – an absolute pittance for Apple. The costs for certification can add up to a bit more depending on which parts Apple uses, but at most it’ll be a few hundred thousand dollar per year, but more likely much less than that. All in all, a total pittance for Apple, and looking at the huge list of gold and silver members, as well as the massive names that are platinum members, losing Apple as a member would barely be a blip on The Open Group’s radar. The silver members alone generate several millions of dollars in revenue each year, so Apple’s contributions really don’t seem all that consequential.
I think the reality is a lot less exciting: deep inside Apple there are probably still a few hardcore UNIX people who do actually really care about this, and they clearly don’t mind spending some work time keeping the certification train going. While the certification document for ARM was written by a fairly new Apple software engineer in the CoreOS group, Mansi Agarwal (who joined Apple in June of 2023), the certification documents for macOS on Intel were written by Fred Zlotnick, who joined Apple in 2015, and has a long history working on UNIX products.
He worked at a company called Mindcraft from 1989 to 1995, which was an Accredited POSIX Testing Laboratory, then spent almost 15 years working for Sun Microsystems on the Solaris operating system, leading teams of dozens of kernel engineers. While at Sun, he worked on the core I/O subsystem of Solaris, the InfiniBand stack, things like the IP, TCP and UDP stacks, ZFS, and more. After a few short stints at other companies, including leading an Illumos kernel team at Nexenta, he ended up at Apple, where he would work until his retirement in 2023.
That’s some serious pedigree, and it’s not difficult to imagine people like that don’t mind breaking, twisting, turning, and mangling macOS to somehow still hammer it through a UNIX-shaped hole. The question is, though, for how long?
Is this like an anger post by an employee of HP or SPaRC* YES you were actively worked against, and you were not supposed to succeed. Itanium was going to be the best thing ever (it sucked even at native code, unless you had some magic jit compiler) But it killed most RISC projects.
Of the RISC projects that still live ARM is the best example, even though some parts are closing in on CISC territory and have to be ripped out to be true to the arch.
Honestly, this doesn’t feel like cheating or lying. it feels like doing any other audit or accreditation. If you think anyone with any of the ISO or similar badges on their website actually Does all the things youll be in for a rude awakening as to the reality.
And yet, Thom pointed out three entire successful OS’s that don’t do any of those manipulations to be able to meet UNIX certification. Just saying, “well, no one does any of that kind of stuff anyway” belies the point that some OS’s DO do all that stuff and that Apple very clearly does not.
For these answers, yes, but for others they do the same.
Standard certification is a money spinner. It’s in their interest to let people pass/pay.
The questions done ask for everything to be in by default. Just that it Can be on.
Take CIS as an example, Redhat and Ubuntu can be made compatible and are therefore certified. Ut out of the box they don’t have all the options enabled. I bet there are other distros that do. Doesn’t make redhat any less CIS compatible.
I would be suprised if anyone here uses AIX or HP-UX for anything other than a few legacy boxes at their place of work. No-one is daily driving those OSes, and the installations of those systems are not exactly increasing at a rapid pace.
Free OSes like Linux distros and BSD have largely superseded true UNIX, and it’s no longer particularly relevant outside of legacy niches or specialised applications. I can totally see someone spinning up a new AIX install on an IBM mainframe, but you’re not going to be running your office file share and web store backend on it.
Let’s look at the bright side: For as long as Apple pursues UNIX® certification for MacOS, MacOS will have a root account and an official process to enable it, which cannot be said for other operating systems such as Android (even stock Android running on the Google Pixels).
And I want to believe that there is something forcing Apple to still seek UNIX® certification decades after they stopped caring about “openness”, don’t spoil it for me. I guess it’s the fact they advertised MacOS as UNIX once and now they are commited, I dunno,
BTW, I can’t blame Apple for the following:
– Shipping APFS as case-insensitive: Having two files called Cat.jpg and cat.jpg in the same directory is downright confusing for most users, and then there is the issue of what happens when you copy such a directory to a FAT32 or exFAT partition (which are case-insensitive). It happened to me on Desktop Linux once, and I got a “file already exists error”. Yes, a “file already exists error”… during a directory copy… good luck explaining that to an average user. So, if Apple wants MacOS users to have a good experience with MicroSD cards (and USB drives which are also usually FAT32 or exFAT), they need to be case-insensitive.
– Disabling core file generation: Most users don’t look at core files, and if they don’t know what core files are, it can fill up their storage pretty quickly, so again, I understand why Apple disabled this feature by default.
– Making the root partition immutable: Not doing that just for the sake of UUCP would prioritize the needs of the very few over the needs of the many. Who uses UUCP anymore? If you do, you are probably knowledgeable enough to copy the uucp utils to /usr/local/bin yourself.
So, what is left is things where the Single Unix Specification is incompatible with modern OS features, and I am talking about essential features such as system integrity protection and file indexing here. Oh, and being incompatible with certain performance optimizations such as filesystem caching that are essential for getting a good performance and battery life (hint: even Dekstop Linux doesn’t mount partitions with strictatime, it kills performance and it also kills SSDs). If you care so much about having strict access times recorded, you have to de-optimize your system a bit yourself, I guess.
So, the only things Apple has really broken are:
1) Making turning off System Integrity Protection a bit harder than it needs to be (because Apple, duh)
and
2) Case-insensitivity, which can indeed break file transfers from other Unixes and can randomly break poorly-coded shell scripts. Sorry Unix people, FAT32 and exFAT conquered the world, those two filesystems are everywhere from MicroSDs to USB thumb drives to MP3 players. if you want case-sensitivity, you have to re-install your OS as case-insensitive.
* re-install your OS as case-sensitive (sorry)
That’s a lot of words to say, “yes I agree, MacOS is clearly not Unix”. Agreeing with every point Thom made and defending them as ‘better for the users’ doesn’t make it any more Unix-y, sorry.
At its default shipping state, MacOS is clearly not Unix, system integrity protection and case-insensitivity alone disqualify it. And what did you expect? SUS is incompatible with what modern users expect from a modern OS, that was my point. You can make it Unix with some effort by following Apple’s instructions and Apple has to provide you with instructions on how to get true root access, so that is worth something, I guess.
Now as to why MacOS can call itself UNIX, that’s the problem of the people granting the certification, not Apple’s. The fact the Single UNIX Specification allows systems to be shipped in a non-compliant state and allows vendors to ship buggy products for 12 months is one of the reasons nobody took the SUS seriously even back in the day. Which is what the Unix vendors of the day wanted: pretend to be compatible with each other without actually being so.
But you are complaining that on Android there are no “root” user even if it’s trivial to achieve it with full reinstall: just open the official instructions ( https://source.android.com/docs/setup/build/building ) build an “eng” build and voila: “root” is there, now.
Convoluted? Sure. But so is full reinstall of MacOS needed to pass the certification.
Google could have just as easily added an instructions and tweaks needed to pass the certification, it just doesn’t care about that.
The above instructions won’t get you Play Store or Play Services, you will only get AOSP. Which can’t run any apps that require Play Services (for example Google Maps or CityMapper). In fact, Google recently make it harder to install Play Services on “non-certified” Android ROMs, s you have to generate developer keys and just through some hoops.
Instead, on Macs the pre-installed operating system already has a root user, you just have to enable it.
Sure, but that’s not the result of certificate but more of because no one bothered to make it impossible to create root user without reinstallation. To switch from case-insensitive mode to case-insensitive mode you need to reinstall macOS, anyway, why couldn’t they include the creation of root in the same process, like Android did?
No, you still don’t get it, Google won’t tell you how to acquire a ROM that has both a root user and Play Services.
Apple tells you how to achieve full root on MacOS while keeping the product intact. And you don’t have to compile a thing or reinstall anything, read the instructions again. Reinstalling is only if you want to change the filesystem to case-sensitive, not getting root. And even then, you don’t have to compile anything or gimp the OS, just re-install the existing OS image.
I think it’s you who don’t understand things. Read what I wrote: I’m just saying that what you may do and not do with macOS is entirely independent from what they have to allow or not allow in the certified version, that’s all!
You say “reinstalling is only if you want to change the filesystem to case-sensitive, not getting root”… but to pass the certification you need both! If Apple would remove the ability to add root without full reinstall… it wouldn’t affect their ability to get the certificate one jot. That means that your coveted ability to get root on a MacOS hinges on the goodwill of Apple and NOT on the certificate, that’s only good for marketing purposes. And Google can easily circumvent the requirement of having to images for certification by just gluing them together and letting installer pick the right bits. Google Play falls in the same category, essentially: Microsoft certified Windows NT 4.0 to be a POSIX compliant OS by disabling networking… why Google couldn’t disable Google Play in the certified version? Certificate would be given anyway.
Good point: In a future version of MacOS, disabling “system integrity protection” could disable lots of other things, for example the UI and drop you to a CLI-only version of the OS. So, I guess we are reliant on Apple’s goodwill to keep giving you a functional MacOS even if you have enabled full root access.
Also, I wouldn’t be surprised if things like Widevine L1 (required by Netflix UHD) don’t work with SIP disabled, much like Android banking apps won’t work on rooted phones.
In this particular instance, Microsoft didn’t disable anything, the POSIX version they implemented in Windows NT 4.0 didn’t define any APIs for network or disk access. The POSIX people assumed you would use Unix-like for networking or filesystem access, but that wasn’t defined anywhere in the spec, so Microsoft called the bluff and never implemented any Unix-like APIs for networking or filesystem access, they implemented the POSIX spec to meet government requirements and just that.
kurkosdr,
I’m not confident that unix certification is so important to apple that it won’t get thrown into the toilet If it runs up against apple’s grand design. But I do agree with your premise here that unix certification requires at least some degree of openness in terms of giving users unixy features like root control over the file system.
It seems to me that apple’s intention was to make app store competition less viable. I’ve personally struggled with SIP on macos when I needed to run downloaded software because it didn’t operate like unix. But at least it’s still possible to sideload if you know how. There’d be more of an uproar if it weren’t.
I typically don’t like to see the same files existing under different letter cases either. However the problem with case insensitivity is that unicode is an evolving standard such that two operating systems can legitimately disagree about file name overlaps. With case sensitive file systems the question of consistency goes away since all filenames are consistently allowed. However as soon as you introduce case insensitivity the case rules for every alphabet supported by unicode needs to be checked for filename collisions
It’s not just the basic alphabet letters, but all variants too – I’m pasting html codes just for the latin letter e for example…
e è é ê ë E È É Ê Ë
I concede most unicode updates these days probably have to do with emojis rather than core languages, but it still is awkward that two case insensitive file systems can disagree over filename collisions. This topic has been discussed on osnews where we talked about windows nt details. The OS character map gets hard coded into the file system at time of format so that if it’s opened on a different OS, the original unicode rules apply rather than newer or older rules. You’d have to reformat the media to update the case tables.
This has bizarre repercussions though, especially if you want applications to perform case insensitive matching. You could have a scenario where the application/OS/filesystem all disagree over collisions. Again I’m not suggesting these corner cases would be common, but it’s weird that it’s a possible outcome.
There are arguments for and against case-sensitivity. Case-insensitivity is closer to how humans think of names, while case-sensitivity has the advantage that two file names won’t be the same unless every single codepoint making up their name are the same (or as you put it, there are no collisions due to assumptions of the comparison logic). But my point is much simpler: FAT32 and exFAT won, end of story. If you go for case-sensitivity, you are introducing the massive headache of having to interface with FAT32 and exFAT that are case-insensitive.
Also, what issues did you have with System Integrity Protection and with what software? Just curious, unless software tries to modify immutable directories, System Integrity Protection shouldn’t be a hurdle.
kurkosdr,
It was postgresql. IIRC it was a home directory install, but honestly I don’t recall the details. Macs are not my forte, any time I do work on one it is because the customer is a mac shop that provides me with one. It probably would have been beneficial to me if macos was UNIX03 compliant out of the box. But in any case with the help of others we got it working.
Ah. I punt that to Macports or Pkgsrc. It was probably complaining about it not being signed. LibreWolf has a similar problem, if it’s the problem I’m thinking of, and it needs to have an xattr added to run.
What I see is that case-sensitivity won, in spite of (ex)FAT. When I put files on a USB stick, I feel like a dinosaur, and it happens maybe once a year. In the age of unicode/UTF8/UTF16, it is madness to think ‘E’ and ‘e’ in a filename should be the same. Computer-literate people automatically know the importance of distinguishing between upper and lower case. It is insane to me that Macs apparently still come with case-insensitivity by default. Even Windows switched long ago, right?
Sure, Apple does not, indeed, certify their operating system in terms of what your own subjective interpretation of what the Unix certification must be or mean. They, however, target and pass the certification of the authority in charge of granting it. Which is what the customers, that may care for such a cert, are looking for.
Which raises the interesting question: Do those customers bother to do all the setup required to get MacOS to pass SUS tests? Do they even know they need to do all this setup? This reminds me of a case where the Greek authorities bought an expensive C4I system from SAIC and Siemens for the 2004 Summer Olympics (with all the certifications and such) that never worked. But the certifications were in place, and that’s what mattrers. Similarly, let’s hope those customers who buy MacOS as a UNIX system don’t try to use their UNIX-certified system as a UNIX system out of the box (with no case sensitivity and no root account enabled).
The certification, in this case, says nothing about out of the box or turn key expectations for a consumer product.
FWIW HP-UX, AIX, and Solaris require also lots of “massaging” when being deployed in order to fit into the infrastructure or app roles.
It happens a lot in government sectors… Various scenarios require you to run products which have some kind of security accreditations, however the accredited configuration is very far from the default, and usually the accredited version is quite old (read: missing security patches) because the process is slow.
Quite often the accredited configuration is unusable or introduces problems – for instance the old C2 certification for windows nt required that the system wasn’t networked and had no removable media.
So everyone cheats, they run software that can theoretically be accredited, but never the accredited version or configuration.
Yes, the devil is in the details, also the fine print and footnotes.
FIPS is another example. Lots of software is FIPS compliant, and lots of software which is FIPS compliant requires configuration to be FIPS compliant.
Some of these sound like sound security settings. If they need to be disabled to get Unix certification, something’s wrong with the certification, itself.
Past that, it sounds like the Unix certification people are desperate to have Apple as a member, even if it is only Silver level.
Unix certification assumes the user needs true root and knows the risks involved. So yes, the Single UNIX Specification is incompatible with security settings that prevent users (including the root user) form changing things directories such as /bin and /sbin.
I would argue that macOS’s Unix certification isn’t a lie.
Yes, there are a few steps you have to take to make it pass the tests, but first of all, they are easily done and well-documented for those who are interested in trying it. Anyone who is interested in running the tests or making macOS as SUS-compatible as possible only needs to spend a couple of minutes to adjust the system to make it so. Those who aren’t capable of doing that also won’t care about it.
Secondly, most of these features are designed to protect the Mac’s primary target group: the average consumer. Others have mentioned other OSes such as AIX, Solaris or HP-UX that don’t require a lot of tweaking to pass the tests. What I haven’t seen mentioned here though is their target audiences. These OSes are only ever used by professionals or enthusiasts who are capable of hardening system security and are more likely to be cautious about what they download and execute on their machine. macOS, on the other hand, is used by such a huge range of different people and the vast majority need the enabled-by-default security features in order to protect them because they don’t know what they’re doing.
I have been using macOS has my primary OS since 10.0 came out and have yet to run into any issues with its Unix-compatibility. Before switching the Mac OS X, I worked a lot with Irix, Solaris and early versions of Linux, so I’m certainly not a stranger to Unix-like OSes.
I’m not actually mad at MacOS being UNIX-certified. I’m more annoyed that real genetic Unixes like the BSDs and Illumos are not certified, mainly because of the cost of the certification. It would be nice if the Open Group would make it free for non-commercial, open-source Unix systems.
The certification isn’t a lie. You can configure MacOS to be compliant to the SUS. So MacOS is a “True Unix”. One has to question if that really means anything in the broad scheme of things, outside of situations where adherence to the SUS is required.
I know the nerdier factions have a weird deference to UNIX, but it’s 2025 and the computing world at large isn’t clamoring for UNIX. MacOS wouldn’t be any less successful without the certification. Nor does being uncertified seem to hurt Unix-like OSes one bit.
Yeah, If the question is “you could configure OSX to be Unix compliant, but why?” I’m pretty sure I’m not going to get any legitimate answers, and definitely not any use cases that aren’t infinitely better served by actual Unix or Linux.
I am not an Apple apologist. But over the decades you just have to laugh at Thom’s idealism. Yes, modern OSes can’t comply with an outdated standard and deliver an simple, secure user experience. Apple provides a way for the dozen people who care to make the OS entirely compatible with this outdated standard, when you want to run ‘uucp’ I guess. The tech world just doesn’t run like Thom would like it to, he’ll never be satisfied, but for most of us, this literally doesn’t matter.
jvanderberg@gmail.com,
I suspect that even a lot of mac users would overwhelmingly object to a fully locked down mac OS. Those who want macos to turn into ios completely handing over the keys “for their own safety” are in the minority.
The standards exist for portability sake. I understand that maybe you don’t personally care about portability and if that’s the case then more power to you. But if you do it is a pain when platforms turn their nose up at standards and deprive end users of control.
I think apple has a significant tech base who care very much. They picked up mac os because it is unix on well supported hardware with an inoffensive GUI. If it weren’t for unix users in tech circles, honestly I’m not so sure that macos would still exist. Apple might have thrown in the towel on macos in favor of ipads with a keyboard.
Almost every Unix/Linux app cross compiles to MacOS with no modification. I just checked out the source code to git on my mac, launched a terminal, typed ‘make’, and a minutes later a working git binary was there. Try this at the windows command prompt.
I also use all sorts of Unix/Linux command line apps on MacOS. I’ve never run ‘uucp’ though.
jvanderberg@gmail.com,
Cross compatibility only works because of unix standards that you are dismissive of. Without compliance with unix standards (be it official or not), macos cross compatibility wouldn’t be viable. So really you should be thankful that macos can still be made compatible with unix standards.
Also, not for nothing but windows is more compatible with linux than macos thanks to WSL2.
I am not dismissive of unix compatibility. MacOS has it. I am dismissive of nit picky idealism that dictates perfection. MacOS has more than good enough Unix compat, it’s really quite good. WSL is more compatible with Linux because, it’s Linux. I can run Linux in a VM on MacOS too.
jvanderberg@gmail.com,
Well, I am not really as opposed to this position. It was the original post that came across as dissing the unix standard and it’s importance for macos compatibility.
Some of the macos tooling is stuck in the past rather than more modern tools. Also apple’s boycot of GPL3 code doesn’t help things…
https://news.ycombinator.com/item?id=18852887
The saving grace here is that 3rd party software repos including macports and homebrew are available. Their maintainers do a better job keeping software up to date. I imagine most power users are familiar with using these repos for updated tools.
“WSL” was microsoft’s implementation of linux. “WSL2” is running a real linux OS with microsoft’s extensions to integrate it into the windows desktop environment (unlike a standard VM). Does apple have that? I don’t see that for macos, but I see other people asking about this too.
https://forums.macrumors.com/threads/is-there-something-like-windows-subsystem-for-linux-wsl-on-mac.2381667/
macOS is a point-in-time OS after all.
People were mad at Apple when they started paring down the software they shipped in base, but it really makes more sense to use the package managers for things that aren’t necessary for building native software for macOS. Sure Python and Ruby in base were nice, but they didn’t add anything. It’s more annoying to have to deal with the old versions in base then install a package manager.
It’s the same situation with point-in-time Linux distros. Move things out of base so they can be upgraded easily and as needed.
I haven’t dissected WSL2, so I might be wrong. I’m under the impression sure most of the modifications are the Hyper-V extensions, which are in most repos, and it’s not piggy back on the work done for the VirtIO drivers.
macOS does have a builtin hypervisor framework, but it doesn’t have a hypervisor of it’s own.
https://developer.apple.com/documentation/hypervisor
Apple could build something similar to WSL leveraging VirtIO drivers which are already well known.
Apple could also keep going down the UNIX route and build more *nix compatibility into the OS itself. A hypervisor and OCI containers would be the two things I’d like to see. Spinning up VMs with a builtin hypervisor is something I miss about Linux when I’m away.
The article contains an entire paragraph dedicated to how little this matters. Did you not read the article?
Reminds me of AIX. “It’s based off SVR2.” It is??
This article is incredibly petty and uninformed about certification processes.
Instead of the clickbait “__blank__ is a lie”, perhaps something like “Deep dive into how MacOS is UNIX certified” as the details were interesting. The opinionated banter was not.
macOS being a certified UNIX is not a lie. It passed all the tests and got certified, that’s it. I fail to see what the problem is here,
I agree; for practical purposes I very much doubt any macOS user misses not having uucp, but everyone loves to have a standard POSIX interface under the hood.
Oh, and, after to some digging, I merged many of the changes they did to FreeBSD for compliance purposes., but FreeBSD has *never* considered bringing stuff like uucp into the base system.
Nerds, nobody cares. About 1000 people probably uses it, big woop. Every body else haven’t even been to the terminal app. EVER. emacs -q –no-splash -f tetris
iluvcrap2000,
Don’t see the point in shaming macos developers. In any case though those “nerds” are likely the only reason macos still exists. If you take the idea of power users being unimportant seriously, then macos as a platform becomes redundant for apple. Without a market for power users, macos would fold into IOS. That might work for you, but not power users. I think it’s incredibly short sighted to be dismissive of the power user aspects of macos, terminal and all.
So Apple now chases the few remaining / dwindling users who teeter on a switch to Linux, is this using the ‘we are Unix” or the “we are not MS” methodology? It seems a bit hazy.
But really, it doesn’t bode well for the future of MacOS when the owner trying to dress it up in the King’s new suit, some of the older individuals among us have seen this sort of thing all before.
macOS runs most of the *nix tools I’m used to without needing a compatibility layer or a magic VM, so it’s a pretty good *nix, in my very lazy standards.
With that being said, macOS is not Unix. LOL
A long time ago, I was playing around with FOSS *nixes, FreeBSD and various Linux distros, but I wanted a desktop that had corporate software support. Or at least more support then FreeBSD or Linux had at the time.
I bought a refurbished 12″ PowerBook with OS X 10.4 Tiger on it, and the OS X missing manual book. I read through the book and did various tasks that I would with a regular FOSS *nix install. I wasn’t the greatest with unix-like operating systems at the time, but I could get around and work with services, install software, etc. As I’m going through the book, I realize this isn’t Unix. FreeBSD and Debian/RHEL are Unix. macOS is not Unix. It doesn’t work like the FOSS *nixes, which are the de facto Unix standard bearers.
macOS is something totally different which is mostly FOSS *nix compatible, and that’s okay. It’s *nix enough that I can easily work with slight modifications to the OS. Versus Windows which is an unholy cesspit of pain when using *nix tools without a magic VM, so macOS being kind of Unix is enough.
Maybe those temporary waivers are accessible for Open Group members? According to the pages linked here there aren’t any though: http://www.opengroup.org/csq/search/t=XY1.html
It does seem valuable that a standard macOS can at least be coaxed into being compliant with some version of UNIX.
Yawn… I use MacOS, Linux, FreeBSD, and v6 and v7 and do exactly what I want with them. Working around some of Mac’s ‘features’ to have the *nix experience I want is no different than it is on the others. Whiner’s gonna whine.
Apple goes through this process due to the settlement of the lawsuit from the Open Group for claiming that MacOS was UNIX in advertising without having a license for the trademark – see https://www.osnews.com/story/3767/unixs-courtroom-adventures-continue/ and https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix-compliant-certified for the backstory there.
BTW, Solaris 11.4 was UnixV7 certified when it was released, but isn’t listed as it hasn’t renewed the certification since then – see https://www.opengroup.org/openbrand/register/brand3642.htm – it had exceptions for things like not necessarily freeing disk space when you remove files, because they may be part of a prior ZFS snapshot – the POSIX file system specifications pre-date copy-on-write filesystems & snapshots.
acoopersmith,
Wow, you’ve got a good memory. Not sure that the legal case about apple misusing the trademark means anything today, but these are extremely interesting articles all the same. I wanted to read more of the osnews article but the cited businessweek link is dead.
That Terry Lambert post about the scale of work that went into making macos compliant is really fascinating too. Thank you for linking it!