Comment by mrweasel

1 year ago

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.

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

      1 reply →

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

      17 replies →

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

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

      3 replies →

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

      1 reply →

    • How is launchd better than systemd? I find the commands much more verbose and the documentation more obscure

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

  • The enterprise support is actually pretty bad. they offer some cool stuff like DEP but there's so many strings attached that for enterprise it's rarely actually possible in practice. Many things are boneheadedly designed.

    For example, Apple federated accounts are a great idea. But, in your global directory the UPN and email must be the same. For us it's not, with good reason. We're not going to change our entire setup globally to suit Mac users that make up 0.5% of our systems. And there's never going to be more unless they become more accommodating. We even looked at JAMF but it's too much work to implement a whole separate management system. And the options in apple's configuration profiles are way too limited.

    Another issue, every account that has already been created as a private Apple id on the corporate email must be manually resolved. Impossible with many tens of thousands of users.

    AD binding while rudimentarily supported, causes so many issues. If someone's password expires there's no way to log in unless they're physically on the company network. The problem is that our security team demand we bind to AD. Not Azure AD. That's just reality in enterprise.

    Having a managed local admin account is also a really big problem and there isn't really any tooling for that.

    Maybe if you go all in on Apple like IBM did, then yeah you could adapt your environment to all their quirks. But it's a big blocker for small deployments. And really besides IBM nobody in enterprise did this. Apple meanwhile doesn't really care anyway. They only care about the customer market.

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

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

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

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

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.

  • 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?

  • 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!)

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

    • The cost isn't negligible. The OS team at Apple is smaller than you'd think and has a tight schedule that cannot ever miss a ship date. Basically anything that uses anyone's attention has to be important.

      > there's the question of who's going to make the call the not update a certification that's negligible within the scope of macOS development.

      And one way that's managed is to have a DRI system which (ideally) prevents this from happening.

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

      3 replies →

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

      2 replies →

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

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.