Not breaking userspace is the first rule of Linux kernel development, but macOS has never had that policy as far as I know. Apple care much more about being able to move fast and clean up bad interfaces in their software, which is a priority I value.
I’m not saying that’s what happened here, but I do know that Apple ultimately expects developers to pay attention to new releases and make sure their software behaves properly with them.
As for standard utilities being broken, I’ve never experienced that on macOS. I do know that Macs get their standard utilities from FreeBSD and not coreutils by default.
The user-space ABIs are widely unstable. Try to run software compiled on Ubuntu 20.04 on 18.04 for example. On macOS, it's just the matter of using -mmacosx-version-min= to make sure that newer functions don't get used.
Or for that matter, even in the reverse case, things break.
Of course that doesn't work. Why would anyone expect it to? Install your baseline distro version in a chroot and set GCC's --sysroot, alternatively use a container, alternatively use a Flatpak SDK, problem solved.
The main problem with this is knowing which libraries have stable ABIs and which don't, which is only documented in a convenient way for enterprise distros (RHEL/SLES).
Making open() returning EINTR possible on regular FS is not really cleaning up bad interfaces. Is there even a precedent on any Unix for that behavior?
Only if the signal that was caught isn't using SA_RESTART: https://pubs.opengroup.org/onlinepubs/9699919799/functions/s... ("If set, and a function specified as interruptible is interrupted by this signal, the function shall restart and shall not fail with [EINTR] unless otherwise specified.")
Therefore, correct code can also not handle EINTR as long as it uses SA_RESTART for all non-fatal signals. That's probably the most common case (nobody likes EINTR).
There are liberally millions of app, Apple can't expect all of them to be always up to date on day one, to even sw like postgres. You can't just change the semantic of an API, it's just wrong. Apple should introduce a new API, deprecate the older one and remove it two or three versions later minimum. They just don't care until people is going to buy their hw.
Traditionally, Apple does not guarantee total ABI stability. They push betas instead to allow people to fix the issues, and then support older releases for multiple years.
Yes, unmaintained software might or might not stay fully functional on macOS for long, but that's not an Apple priority.
I’m not saying that’s what happened here, but I do know that Apple ultimately expects developers to pay attention to new releases and make sure their software behaves properly with them.
As for standard utilities being broken, I’ve never experienced that on macOS. I do know that Macs get their standard utilities from FreeBSD and not coreutils by default.