So for those who, like me, wonders why Apple keeps getting macOS Unix certified, it's to avoid a lawsuit. Apple misused the Unix trademark when they first launched MacOS, so to avoid legal trouble with The Open Group, Terry Lambert was put in charge of getting MacOS Unix compliant and certified: https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix...
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.
> 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.
I'd say that you care about it being UNIX-like, not UNIX®. You don't care that Linux isn't UNIX. You don't care that GNU versions of things like ed and awk are slightly off-spec.
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.
> 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.
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
Pretty sure GNU coreutils really does intentionally deviate from POSIX compliance in a handful of places, otherwise POSIXLY_CORRECT wouldn't exist. That said you're probably right, though I also suspect dealing with GPL licensing is another major reason they don't bother with things like GNU coreutils. (Obviously they definitely wouldn't have done it after coreutils switched to GPLv3, but I'm sure even before then they would've greatly preferred permissively-licensed software.)
> I'd say that you care about it being UNIX-like, not UNIX®.
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 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.
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.
Yeah, except Apple dogfoods macOS to build most of the software for Macs and everything else they make. Presumably they rely on UNIX-like tools and would have to retool as well. So why mess with what’s working for them and others?
Given that both grep and find are weird/inconsistent between BSD/GNU versions, and I typically use them piped together for the same things anyway, I’ve found that ripgrep is a nice/faster/universal alternative that is pretty unproblematic to install in whatever environment I want: https://github.com/BurntSushi/ripgrep
There are patches required. Many GNU utilities are very close to the UNIX spec, but not quite the UNIX spec - including glibc. But making a Linux distro that is UNIX certified would likely make it a worse Linux distro for most people since it would be less compatible with what everyone is assuming for a Linux distro. A lot of the differences are subtle edge cases, but do you really want that in your distro?
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.
> 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'm not sure why you would. I don't think POSIX generally specifies the behavior of command line tools in such a level of detail. FWIW, the regex type used by default by GNU Grep is already POSIX's Basic Regular Expressions. (It also supports POSIX Extended Regular Expressions and PCRE2.)
Afaik, EulerOS and other Unix-certified Linux distros just ship the usual GNU userland.
The Single UNIX Specification does specify the behavior of many command line tools like ed, grep, awk, etc. OpenBSD sometimes notes where their tools vary from the UNIX spec. It's usually very small ways that don't matter to most people, but it does put them outside of the UNIX spec.
> because macOS is adhering to the UNIX specification
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.
There is absolutely no way that happens. Apple cares about Unix compatibility for very good business reasons. Apple gets a lot of value from being even just Unix-ish. It's the same reasons Microsoft eventually knuckled under and made WSL -- the ubiquity of Unix conventions and tooling is just too cemented in the industry.
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.
While macOS only really gets Unix certified they design of the flavor of unix from FreeBSD. Homebrew is also the best port system and package manager I have ever used because it requires no thinking. I actually dislike using Linux because now I have to learn the replacement from ifconfig, the creation of launchd IMHO is way better than init.d and systemd, and the command line diskutil and other additions still feel like its more Unix like while Linux feels like its moving toward its own thing. Before I was using macOS I was using OpenBSD as my daily driver since high school. I still don't understand though why Ubuntu has the ability to break /boot because there isn't enough space to add another kernel to there...
I’m going to comment on the homebrew part because well that’s your tastes but I personally think it’s the worst package manager I have ever used and is not really a port system so opinions do vary here.
> 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.
Homebrew is pretty nice. I think it's better than Fink (mac DPKG), and MacPorts (mac Freebsd-based). I'm actually using homebrew right now on ubuntu 25 for a few packages that I don't feel like compiling from source or installing from some random PPA or apt source.
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.
It's not for everyone, but at some point I got tired of the FreeBSD layer being there but not cared for, and WSL+git for windows kinda provides a decent compromise in that regard.
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.
Agreed, WSL + Windows Terminal on Windows is fantastic. I hope something similar comes to macos, to save us from either running docker local or SSHing to a linux host.
The initial argument was that MacOS is nice because it has the core Unix tool. I find this baffling because MacOS has very little to do with a traditional Unix apart from the certification and the core utils are literally usable on approximately anything.
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.
When producing cross-platform software I find creating it on Linux first to be the most cost effective. Porting it to macOS has the least resistance. Windows is where it cost more time and code to release.
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.
Windows does have quirks: MSI installers, Inno Setup, NSIS, and custom EXEs may or may not support silent mode. When they don’t, automation is ugly (AutoIt, AutoHotKey).
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.
Please note, you are assuming I have the ability to control the version of Windows the product lives on. Some products still have to support up to Windows XP.
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.
If you mean UNIX System V via green phosphor text terminals, thankfully not.
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.
That’s as vague as it gets. The amount of things various Unix have in common is, well, not that much. Not that people care in any way because frankly speaking no one uses Unix.
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.
With the way Apple is running its App stores, do you honestly believe that we would benefit from an Apple 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.
There are some infuriating issues though, I have wiped out a couple files on OSX using sed with the -i option to replace a text within a file only to realised OSX would wipe it out instead ....
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.
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.
Because of the heavy push to GPL v3 by GNU, and because Apple’s interpretation of the license’s patent requirements prevented any GPL v3 code use, very few GNU projects remain as part of macOS.
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.
That's my question too, why continue to bother? Apple doesn't even have any separate "Server" OS anymore. I can't find anything mentioning UNIX on any apple.com marketing pages.
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.
Not at Apple and don't have any knowledge here, but I'd imagine that the UNIX test suite, ever since it began passing, has been a useful set of additional regression tests even outside the certification context.
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!)
My (wholly unsupported) guess is that there are government or megacorp bids somewhere for Unix systems for employees, and this checks that box. The buyer could update their requirements, but why do that when you can just make your vendor jump through the hoop?
I obviously don't know, but I could easily imagine that Apples legal team has flagged it as a potential risk and the cost of keep the certification up to date is minimal, compared to some imagined risk. Safer to pay the fee, and not having to worry about someone at Apple accidentally calling macOS a Unix system in public.
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 isn't much downside, but it probably involves a small amount of money (paid for the certification) and it means spending time making sure that everything remains 100% within spec. There's lots of little edge cases where BSDs differ from the spec and it means that Apple needs to take care not to drift from the spec.
As pointed out by amiga386 both here[1] and in earlier posts, macOS is not actually compliant with the Unix spec and never has been. This has apparently not been a hindrance for the certification of every single non-compliant version. Unix certification for Apple might not involve anything other than payment.
It’s a spec that doesn’t really matter in practice. Like some other comments said, Linux, BSD and Solaris are “Unix but not Unix(tm)”, and nobody cares.
I think it’s a quiet but deliberate strategy to keep macOS the spiritual successor to NeXTSTEP. While many of Jobs principles are under pressure at current day Apple, his ghost lives on.
I think you mean literal successor. It's descended from NeXT's codebase. Mac OS X 10.0 was basically NeXTSTEP 6 with Apple logos, Carbon and a Mac OS 9 VM.
There's a "ship of theseus" problem with this idea. There's enough different about OS X (different kernel and BSD base, different display server, different driver stack) that I think it's fair to describe it as a separate OS, yet clearly a lot _is_ directly taken from NS, especially the ObjC/application layer stuff. The waters are further muddled by the existence of Rhapsody and OS X Server 1.0, which are much more clearly "NeXTSTEP 6 with Apple logos, Carbon and a Mac OS 9 VM". I don't think anyone outside the original OS X development team really knows just how much code was kept vs scrapped for the start of OS X development. Given that NS/OS was based on USL-encumbered BSD, it seems likely to me that nothing from the original NS kernel was kept for that, at a minimum.
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!
There’s an interesting story from the lead engineer to make OS X originally compliant:
> 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.
> 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.
Two general-purpose Linux distributions used to pay for Unix certification, although they don't do it anymore since hardly anyone is interested in it these days.
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.
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.
There was a time when “open standards” were treated as the definition of Unix. At least that's what we aspired to. POSIX, X/Open, and others competed to be the standard that mattered. Formal standards were hoped to be a sounder, fairer basis for compatibility and interoperability than the earlier era of “Unix is whatever this release says it is" for some subset of 7th Edition, System III, System V, BSD, or one's favorite commercial derivative (SunOS/Solaris, HP/UX, AIX, Xenix, UnixWare, ...).
That window window of optimism—roughly mid-1980s to mid-1990s—closed fast. Open source projects and _de facto_ standards proved far more powerful in deciding where applications would run, where investments would be made, and which variants survived. Today, the real baseline isn’t POSIX in a binder or some Open Group brand certificate, but Linux + GNU + the APIs everyone codes to. In some ways we've regressed—or more charitably, we shifted back to a more pragmatic form of standardization.
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.
is not controlled by a corporation whose only motive is profit
Instead it's a bunch of corporations with very similar motives, including profit, so the end result isn't all that different. Just look at who the majority of committers work for.
> 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.
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.
Can there ever be a "living" standard to replace posix ...? Something that captures the good things about posix but allows all the related ecosystems to move everyone forward toward a better base specification (together rather than just increasing the number of bsd vs gnu special cases that with current plans will just have to be lived with forever)
Browser standards managed to do this in a lot of ways despite far more complex standards, more complex variations in behavior, and much more rapid continue evolution ...
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.
And here I just want pthread_condattr_setclock() on Darwin. Is there some other interface to set monotonic expiries? I tried to port netconsd to Darwin and that's the sole hang up (well and recvmmsg() but that's trivial...)
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.
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):
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.
I wish jq would be in the posix standard. JSON is EVERYWHERE nowadays. A system that can’t parse it is incomplete. Not having a standard way to write a script that does it and works across *nixes is a mistake.
I'm not even talking about compilers though... all I want is a baseline standard that I can point to and say: "Here. This right here is where it says that 'curl' and 'wget' shall be available and in $PATH."
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.
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.
Think of it: it's a Unix system. Literally. A unix system with the usability that your grandma can use. It supports both commercial and open source applications. The year of the linux desktop folks have been trying this for decades.
EDIT: already downvoted to negatives. The Linux folks really don't like to be reminded of that.
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 claim is that the linux community has been trying for decades to create a desktop with the usability that your grandma can use it. the implied claim is that they failed, which is of course nonsense. linux has caught up with the usability of mac os a decade ago, if not before that.
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.
So for those who, like me, wonders why Apple keeps getting macOS Unix certified, it's to avoid a lawsuit. Apple misused the Unix trademark when they first launched MacOS, so to avoid legal trouble with The Open Group, Terry Lambert was put in charge of getting MacOS Unix compliant and certified: https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix...
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.
> 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.
I'd say that you care about it being UNIX-like, not UNIX®. You don't care that Linux isn't UNIX. You don't care that GNU versions of things like ed and awk are slightly off-spec.
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.
> 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.
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
Pretty sure GNU coreutils really does intentionally deviate from POSIX compliance in a handful of places, otherwise POSIXLY_CORRECT wouldn't exist. That said you're probably right, though I also suspect dealing with GPL licensing is another major reason they don't bother with things like GNU coreutils. (Obviously they definitely wouldn't have done it after coreutils switched to GPLv3, but I'm sure even before then they would've greatly preferred permissively-licensed software.)
> I'd say that you care about it being UNIX-like, not UNIX®.
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 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.
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.
Yeah, except Apple dogfoods macOS to build most of the software for Macs and everything else they make. Presumably they rely on UNIX-like tools and would have to retool as well. So why mess with what’s working for them and others?
Built-in grep is thankfully not as odd as the builtin find is. Might be the first one I replace on my systems.
Given that both grep and find are weird/inconsistent between BSD/GNU versions, and I typically use them piped together for the same things anyway, I’ve found that ripgrep is a nice/faster/universal alternative that is pretty unproblematic to install in whatever environment I want: https://github.com/BurntSushi/ripgrep
And also fd https://github.com/sharkdp/fd
But isnt that what AI is for? Writing syntactically correct regexes?
Some Linux distros have gotten certified. I assume they have released necessary patches as required by GPL.
I don't think any patches are required. It's literally just a matter of going through the certification dance for the average distro.
There are patches required. Many GNU utilities are very close to the UNIX spec, but not quite the UNIX spec - including glibc. But making a Linux distro that is UNIX certified would likely make it a worse Linux distro for most people since it would be less compatible with what everyone is assuming for a Linux distro. A lot of the differences are subtle edge cases, but do you really want that in your distro?
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.
> 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?
How close are the GNU coreutils with the POSIXLY_CORRECT environment variable set?
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.
Don't you have to ship the BSD-compatible versions of grep et al?
I'm not sure why you would. I don't think POSIX generally specifies the behavior of command line tools in such a level of detail. FWIW, the regex type used by default by GNU Grep is already POSIX's Basic Regular Expressions. (It also supports POSIX Extended Regular Expressions and PCRE2.)
Afaik, EulerOS and other Unix-certified Linux distros just ship the usual GNU userland.
The Single UNIX Specification does specify the behavior of many command line tools like ed, grep, awk, etc. OpenBSD sometimes notes where their tools vary from the UNIX spec. It's usually very small ways that don't matter to most people, but it does put them outside of the UNIX spec.
> because macOS is adhering to the UNIX specification
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.
https://developer.apple.com/library/archive/documentation/Da...
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.
brew install grep?
brew is such a treasure.
and kind of a counter point to the GGGP's "Unix compliancy isn't what's keeping me on macOS, the Unix tools it has under the hood still is."
I certainly replace a large chunk of the "unix tools under the hood" with tools installed via homebrew.
There is absolutely no way that happens. Apple cares about Unix compatibility for very good business reasons. Apple gets a lot of value from being even just Unix-ish. It's the same reasons Microsoft eventually knuckled under and made WSL -- the ubiquity of Unix conventions and tooling is just too cemented in the industry.
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.
While macOS only really gets Unix certified they design of the flavor of unix from FreeBSD. Homebrew is also the best port system and package manager I have ever used because it requires no thinking. I actually dislike using Linux because now I have to learn the replacement from ifconfig, the creation of launchd IMHO is way better than init.d and systemd, and the command line diskutil and other additions still feel like its more Unix like while Linux feels like its moving toward its own thing. Before I was using macOS I was using OpenBSD as my daily driver since high school. I still don't understand though why Ubuntu has the ability to break /boot because there isn't enough space to add another kernel to there...
I’m going to comment on the homebrew part because well that’s your tastes but I personally think it’s the worst package manager I have ever used and is not really a port system so opinions do vary here.
> 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.
Thank you for correcting me I appreciate it I will use those new commands.
Homebrew is pretty nice. I think it's better than Fink (mac DPKG), and MacPorts (mac Freebsd-based). I'm actually using homebrew right now on ubuntu 25 for a few packages that I don't feel like compiling from source or installing from some random PPA or apt source.
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.
How is launchd better than systemd? I find the commands much more verbose and the documentation more obscure
It's not for everyone, but at some point I got tired of the FreeBSD layer being there but not cared for, and WSL+git for windows kinda provides a decent compromise in that regard.
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.
Agreed, WSL + Windows Terminal on Windows is fantastic. I hope something similar comes to macos, to save us from either running docker local or SSHing to a linux host.
Considering the core utils have even been ported to Windows, I don’t really see what you would lose.
The Unix don’t really share much between each other apart from a small core.
While true, there are still speed bumps on Windows.
One is better using the Windows alternatives.
The initial argument was that MacOS is nice because it has the core Unix tool. I find this baffling because MacOS has very little to do with a traditional Unix apart from the certification and the core utils are literally usable on approximately anything.
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.
When producing cross-platform software I find creating it on Linux first to be the most cost effective. Porting it to macOS has the least resistance. Windows is where it cost more time and code to release.
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.
Windows does have quirks: MSI installers, Inno Setup, NSIS, and custom EXEs may or may not support silent mode. When they don’t, automation is ugly (AutoIt, AutoHotKey).
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.
Please note, you are assuming I have the ability to control the version of Windows the product lives on. Some products still have to support up to Windows XP.
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.
If you mean UNIX System V via green phosphor text terminals, thankfully not.
Speed bumps regarding compilation of tooling written with UNIX semantics in mind, without taking into consideration Windows development culture and OS semantics.
What are these mythical Unix 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.
Everything that UNIX has and Windows doesn't.
That’s as vague as it gets. The amount of things various Unix have in common is, well, not that much. Not that people care in any way because frankly speaking no one uses Unix.
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.
It is super easy, pick any random UNIX tutorials and follow it using Visual Studio, or Windows Terminal.
> I still get everything that I need from a "Unix like" standpoint
Everything except a package manager!
With the way Apple is running its App stores, do you honestly believe that we would benefit from an Apple 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.
Majority of people use homebrew. There is also macports.
UNIX never had a package manager.
Those that have one, it is not standard.
There are some infuriating issues though, I have wiped out a couple files on OSX using sed with the -i option to replace a text within a file only to realised OSX would wipe it out instead ....
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.
AFAIK Stallman didn't care about UNIX, considering he is more of a LISP guy. GNU targeted UNIX because it was the popular OS at the time.
Nailed it.
I don't think Richard Stallman much cares. The first thing every programmer does on a Mac is install GNU software.
Not really.
Sure, I guess. I'd love to meet this "real developer" who doesn't git pull anything to their Mac.
Me, I live in the real world and got dotfiles to clone.
Git's not a GNU project.
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.
Because of the heavy push to GPL v3 by GNU, and because Apple’s interpretation of the license’s patent requirements prevented any GPL v3 code use, very few GNU projects remain as part of macOS.
Git is not a GNU project and is GPL v2.
Hello.
Install everything XCode and use proper UNIX tools already installed.
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.
That's my question too, why continue to bother? Apple doesn't even have any separate "Server" OS anymore. I can't find anything mentioning UNIX on any apple.com marketing pages.
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.
Workstations, although I wouldn't consider the existing alternatives much of a proper workstation.
How exactly would you define a workstation?
A Mac Pro, with the same extension capabilities.
Which extension capabilities?
I gave you the model, check what is available.
Not at Apple and don't have any knowledge here, but I'd imagine that the UNIX test suite, ever since it began passing, has been a useful set of additional regression tests even outside the certification context.
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!)
My (wholly unsupported) guess is that there are government or megacorp bids somewhere for Unix systems for employees, and this checks that box. The buyer could update their requirements, but why do that when you can just make your vendor jump through the hoop?
Probably a government contract.
I obviously don't know, but I could easily imagine that Apples legal team has flagged it as a potential risk and the cost of keep the certification up to date is minimal, compared to some imagined risk. Safer to pay the fee, and not having to worry about someone at Apple accidentally calling macOS a Unix system in public.
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 no downside as far as i’m aware.
There isn't much downside, but it probably involves a small amount of money (paid for the certification) and it means spending time making sure that everything remains 100% within spec. There's lots of little edge cases where BSDs differ from the spec and it means that Apple needs to take care not to drift from the spec.
As pointed out by amiga386 both here[1] and in earlier posts, macOS is not actually compliant with the Unix spec and never has been. This has apparently not been a hindrance for the certification of every single non-compliant version. Unix certification for Apple might not involve anything other than payment.
[1]: https://news.ycombinator.com/item?id=45239534
Apple remaining in spec sounds like a good thing from a compatibility point of view.
Am I missing something? I’m not sure why it’s coming off like people are complaining about this?
It’s a spec that doesn’t really matter in practice. Like some other comments said, Linux, BSD and Solaris are “Unix but not Unix(tm)”, and nobody cares.
Presumably certification costs money (?)
Probably a small amount especially when they just need to tell them what changed
Given how little their target market cares about being a "real" unix, a small amount is probably more than the benefit it brings in.
We are talking about it.
Famous last words
I think it’s a quiet but deliberate strategy to keep macOS the spiritual successor to NeXTSTEP. While many of Jobs principles are under pressure at current day Apple, his ghost lives on.
I think you mean literal successor. It's descended from NeXT's codebase. Mac OS X 10.0 was basically NeXTSTEP 6 with Apple logos, Carbon and a Mac OS 9 VM.
There's a "ship of theseus" problem with this idea. There's enough different about OS X (different kernel and BSD base, different display server, different driver stack) that I think it's fair to describe it as a separate OS, yet clearly a lot _is_ directly taken from NS, especially the ObjC/application layer stuff. The waters are further muddled by the existence of Rhapsody and OS X Server 1.0, which are much more clearly "NeXTSTEP 6 with Apple logos, Carbon and a Mac OS 9 VM". I don't think anyone outside the original OS X development team really knows just how much code was kept vs scrapped for the start of OS X development. Given that NS/OS was based on USL-encumbered BSD, it seems likely to me that nothing from the original NS kernel was kept for that, at a minimum.
This also doesn’t explain anything? Is getting Unix certified a jobs principle or a requirement to be a “spiritual successor”?
Jobs was very much anti-UNIX and is relatively easy to find it out.
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.
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.
I don't think Solaris is Unix certified anymore. It was previously, but the current supported versions are not.
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!
They definitely are, not all though, HP-UX is on life support.
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.
Exactly. They exist but just barely.
Enough to pay salaries of those making them go.
There’s an interesting story from the lead engineer to make OS X originally compliant:
> 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
And if you read further in the comments, he never got the stock. The executive who promised it to him “took it for himself.”
And left his wife for an HR person, can't forget that. Lol sounds like a shitshow all around when it comes to execs but wouldn't be surprised.
Guess it shows that when it comes to compensation promises always get it in writing.
That's always true but especially when working with so many psychopaths
Damn. Don't ever agree to something like this without getting it in writing.
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.
Where do you see that?
Sorry, I’m probably missing the obvious.
It’s in there:
“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.”
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.
Two general-purpose Linux distributions used to pay for Unix certification, although they don't do it anymore since hardly anyone is interested in it these days.
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".
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.
this talk of GNU being "standard" is toxic, as if anything that doesn't use it is weird or off spec.
the GNU userland might be common for user facing systems, but it's nowhere close to standard.
It's the de facto standard. No one knows how to use other flavors of tools like date, find, grep, sed etc.
Some of us do, but we are old enough to know that Linux is not a synonym for UNIX, and to have installed it from floppies.
For all the good that does you running modern software. "UNIX support" in a post k8s age is considered optional.
actually with docker and K8s we see Alpine used more and more, and that doesn't come with a GNU userland.
Thankfully not everything needs Kubernetes.
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.
GNU utilities won. That's just reality.
Citation needed.
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.
The UNIX specification is not the same as POSIX: https://en.wikipedia.org/wiki/Single_UNIX_Specification.
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.
Posix is a subset of the Unix standard - it's necessary, but not sufficient to pass Unix certification.
Reminded of the origin story of making Mac OS X Unix certified: https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix...
Thanks for the link, that's a good read.
Related:
https://www.osnews.com/story/141633/apples-macos-unix-certif...
Identical changes were made for Tahoe's certification. This includes disabling SIP.
https://www.opengroup.org/csq/repository/noreferences=1&RID=...
So Tahoe is certified, but what ships with every Mac isn't certified UNIX. Not that being certified makes any difference what-so-ever.
There was a time when “open standards” were treated as the definition of Unix. At least that's what we aspired to. POSIX, X/Open, and others competed to be the standard that mattered. Formal standards were hoped to be a sounder, fairer basis for compatibility and interoperability than the earlier era of “Unix is whatever this release says it is" for some subset of 7th Edition, System III, System V, BSD, or one's favorite commercial derivative (SunOS/Solaris, HP/UX, AIX, Xenix, UnixWare, ...).
That window window of optimism—roughly mid-1980s to mid-1990s—closed fast. Open source projects and _de facto_ standards proved far more powerful in deciding where applications would run, where investments would be made, and which variants survived. Today, the real baseline isn’t POSIX in a binder or some Open Group brand certificate, but Linux + GNU + the APIs everyone codes to. In some ways we've regressed—or more charitably, we shifted back to a more pragmatic form of standardization.
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.
is not controlled by a corporation whose only motive is profit
Instead it's a bunch of corporations with very similar motives, including profit, so the end result isn't all that different. Just look at who the majority of committers work for.
The best “standards” just ratify what people are already doing.
OK, great.
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
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?
Can there ever be a "living" standard to replace posix ...? Something that captures the good things about posix but allows all the related ecosystems to move everyone forward toward a better base specification (together rather than just increasing the number of bsd vs gnu special cases that with current plans will just have to be lived with forever)
Browser standards managed to do this in a lot of ways despite far more complex standards, more complex variations in behavior, and much more rapid continue evolution ...
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.
And here I just want pthread_condattr_setclock() on Darwin. Is there some other interface to set monotonic expiries? I tried to port netconsd to Darwin and that's the sole hang up (well and recvmmsg() but that's trivial...)
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...
macOS 26? I'm still on 15.6 -_-
apparently sequential version numbers is not in the spec.
I recently learned that macOS has a (by default) case insensitive filesystem. How does this line up with the certification?
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.
Apple calls out case-sensitivity as a change they made to pass certification. [0]
> 3. APFS file systems can be formatted as either case-sensitive or case-insensitive. Always format as case-sensitive for UNIX Conformant behavior.
[0] https://www.opengroup.org/csq/repository/noreferences=1&RID=...
If they standardize mktemp ( https://www.austingroupbugs.net/view.php?id=1616 ) then I think you could just
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.
How much stuff breaks when you do that?
There's commercial software that will not run on a case-sensitive file system, such as Photoshop.
If you're using 3rd party software, you don't want to format your default volume with case-sensitivity enabled.
Has there been any work for something post Unix 03?
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.
I wish jq would be in the posix standard. JSON is EVERYWHERE nowadays. A system that can’t parse it is incomplete. Not having a standard way to write a script that does it and works across *nixes is a mistake.
C17 support is required in latest standard.
I'm not even talking about compilers though... all I want is a baseline standard that I can point to and say: "Here. This right here is where it says that 'curl' and 'wget' shall be available and in $PATH."
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.
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...
Solaris did support it, I guess it was more relevant when there were multiple vendors
same for sequoia as well, discussed here: https://news.ycombinator.com/item?id=41698775
Think of it: it's a Unix system. Literally. A unix system with the usability that your grandma can use. It supports both commercial and open source applications. The year of the linux desktop folks have been trying this for decades.
EDIT: already downvoted to negatives. The Linux folks really don't like to be reminded of that.
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™.
the claim is that the linux community has been trying for decades to create a desktop with the usability that your grandma can use it. the implied claim is that they failed, which is of course nonsense. linux has caught up with the usability of mac os a decade ago, if not before that.
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.
Windows 2000/NT POSIX support was the bare minimum, it isn't comparable.
It only got usable when SUA came to be.
my grandma used linux. in 1995!
Good thing to know when I go back to 1980s with a macbook!