(According to wikipedia: All versions of macOS from Mac OS X Leopard to macOS 10.15 Catalina, except for OS X Lion,[68] have been registered on Intel-based systems, and all versions from macOS 11 Big Sur, the successor to macOS Catalina, to macOS 14 Sonoma have been registered on both x86-64 and ARM64 systems.)
I wonder what's the reason for Apple to do this though? Convincing more people to run a macOS server instead of a Linux/BSD one is unlikely the reason (in my mind), but it doesn't make any other sense either...
Official Unix certification may matter at workplaces and institutions where such certifications are required for meeting some type of compliance criteria. For example, if I remember correctly, early versions of Windows NT had a POSIX compatibility layer, which was crucial for getting Windows NT accepted by some US government agencies.
Still, I hope Apple resurrects their server line… hardware and software. It’d be nice to have a server oriented UNIX running on Apple Silicon without resorting to Linux.
It originally showed up in Linux, but it's pretty much universal except for MacOS. I mostly hope they start taking the "unix" part of the OS seriously again. It's been almost frozen in time.
Being certified Unix has nothing to do with being based on Unix code either anymore, Huawei paid for their Linux distro based on RHEL (EulerOS) to be certified Unix once.
> Being certified Unix has nothing to with being based on Unix code…
Never has. In very simple terms, it was always about standardizing OS interfaces for variant Unices. Over time, it’s moved on to be aligned with POSIX.
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.
I don't know how much it costs for the Open Group to certify an OS as UNIX compliant (if anything).
A lot of the time, things are compliant in most of the common stuff, but they might not implement all of UNIX or POSIX. Close isn't compliant, but it's enough that most people don't care. For example, do you care if your Linux disto comes with the `pax` command? Or do you just use `tar`?
Apple had started calling OS X UNIX and was being sued for calling it UNIX when it wasn't actually UNIX. They decided it'd be cheaper to do the work to make OS X UNIX compliant than to deal with the lawsuit and that's what they did. BSDs never cared about calling themselves UNIX so they never went into the nitty gritty of making themselves UNIX compliant.
I agree, though I feel compelled to post that the BSDs learned their lesson about the use of the UNIX trademark the hard way. Part of what caused the classic lawsuit between the Regents of the University of California (the "Berkeley" in Berkeley Software Distribution) and AT&T was the fact that a spinoff company selling BSD had the phone number 1-800-ITS-UNIX:
This lawsuit happened (1992-1994) when Linux was in its infancy (Linus Torvalds started work on Linux in 1991). Had the future of BSD not been so uncertain during this lawsuit, it is quite possible that some derivative of BSD would be the dominant FOSS operating system today instead of Linux.
Linux's dominance might still have emerged due to the individuals behind it. Beyond Torvalds' work on the kernel, Richard Stallman and others had a significant influence in shaping its early trajectory. Their philosophies and actions were key in driving the open-source movement forward.
The BSD license, while appealing to corporations due to its permissive nature, allows proprietary entities to incorporate the code into their products without giving back to the community. This has happened multiple times, with examples like Apple's Darwin, NetApp, QNAP, and Sony's PlayStation systems.
The GPL, on the other hand, attracted early contributors because it ensured that their work would remain open and shared with the world, rather than being exploited for profit.
This sounds rather dry and abstract. What I would rather like to know is: If I installed Sequoia on my x86_64 Mac, what would I lose in comparison to Ventura? I assume newer OSs increasingly drop x64 support.
Historically, the US Government. NIST mandated that only those operating systems should be used where existing applications can easily be ported to and fro, and POSIX compliant OS-s tick all the boxes. Windows NT got its POSIX subsystem for this reason: https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
Most cross-platform applications for desktops and servers. If you write to the POSIX standard, it will work on a wide range of systems. Many applications don't need to go beyond that.
I think it’s what you’re used to. I’m used to the Mac keyboard (since 1994) and I much prefer the command key for keyboard shortcuts. I can use my thumb all day but pressing control with my pinkie starts to hurt really quickly!
You can’t, basically. The copy key isn’t configurable for example, you’d need to rewrite the apps from source to achieve this. Some dynamically link to shared library UI toolkits that you could patch, others implement it themselves… it’d be a never-ending game of finding new broken apps and fixing them one by one (and that’s for open source apps, forget closed source ones.)
You could map Cmd to Ctrl but that only fixes copy/paste, but now it will send a SIGTERM to the terminal on Cmd-C now, which means that’s still a pain.
You could write some custom keyboard driver that intelligently maps the command keys to the right keys the app expects, dynamically based on some rules, but that sounds horribly brittle and likely unworkable.
It’s not really an issue for me because I use a Mac. Having said that, I did remap the caps lock key to control which helps a lot. I usually press it with my ring finger.
I love CMD because it’s part of the copy/paste shortcut but not used for any terminal control codes. So there’s no confusion about whether you’re going to accidentally SIGTERM something in the terminal by trying to copy text.
I really really wish I could have this behavior on Linux… but alas, every app under the sun chooses its own copy/paste shortcut and they all use ctrl+C/V by convention so you can’t configure it globally without rewriting every app (ok maybe you could narrow it down to a few GUI libraries like gtk/qt/etc but it’s still a huge undertaking.)
I’d settle for “ctrl-c is copy if text is selected, SIGTERM otherwise” logic, which I think Windows’s console uses, but none of the Linux terminals I’ve tried support that. I’m left with ctrl-shift-C for copy, which leaks into my muscle memory, then I accidentally use that combo in the web browser too and it opens developer tools or something. So annoying.
I can’t stand X11-style copy-on-select/middle-click-paste, and disable that everywhere if that’s what you’re referring to. I habitually highlight text as I read it and hate it when it blows away my existing copy buffer. I want explicit copying, I just don’t want it to collide with SIGTERM.
Shift+ins is CUA, an actual standard. Which makes far more sense than parroting Microsoft’s decision to use CTRL as a modifier, aping Mac OSs keyboard shortcuts in Windows 3.1.
That’s fine for paste, but copy is the real problem. Also, shift and insert are very very far apart from each other and are not one-handable if you’re holding the mouse with the other hand.
Copy is Ctrl+Ins, cut is Shift+Del. Looking at my ANSI keyboard, all are achievable with one hand. Though, when these were designed, GUI’s on IBM based machines weren’t really a thing and two-handed keyboard shortcuts were common-place.
With a right handed mouse it’s hard to do Ctrl+Ins with my left hand. But it’s possible, I’ll admit. It’s just pretty suboptimal given how ergonomic Cmd+C is on a Mac keyboard (thumb on Cmd is way easier to reach for than pinky on ctrl, and reaching for ctrl+Ins is harder than either.)
Yeah, mice weren’t really a thing on the early IBM AT’s and clones when CUA was being developed. Mice were around and the GUI was very rudimentary (Windows 2.0), certainly when compared to System 4 and 5. In an ideal world, the Meta key, like those found on Sun keyboard, would have been brought over to AT keyboards to cover this.
The brown M&M test is: can you call poll() on a terminal device?
This lack of functionality has been in existence since Mac OS X's inception. It's the reason why a cross-platform software _always_ has to support both select() and poll() to check if a user is typing on the terminal -- select() just for Mac OS X, and poll() for every other system. Wouldn't it be nice if we could standardise on poll()?
Certification aside, Linux and macOS are so similar that I only think about the difference in the rare instances where they differ: three that come to mind are xdg-open vs. open , systemd vs. launchd, and sed -i vs. sed -i ''.
GNU coreutils often have many different options than their BSD counterparts. They both (generally) share a POSIX-specified base wrt options and behavior, but if you commonly only work with one of the two, it's easy to accidentally write non-portable shell scripts.
Marketing. They called OS X, as it was at the time, ‘UNIX’ but didn’t pay the Open Group for certification. The Open Group sued, and Apple figured it was cheaper to certify, so they did, and have done ever since.
They claimed it and then had a choice of either compliant or pay $200 million.
Why did they claim it? They’re trying to justify the $475 million they already spent merging with NeXT? Early Mac OS X stuff wasn’t well received, especially their early server product based on Rhapsody.
I mean I know for all practical purposes that this really doesn’t mean much, but it means a lot to me; I was a big Sun guy back in the day, and a dash if Irix here and there.
70 comments
[ 3.0 ms ] story [ 117 ms ] thread[0] https://news.ycombinator.com/item?id=41698775
> it was done to get Apple out of a $200M lawsuit filed by The Open Group, for use of the UNIX™ trademark in advertising.
https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix...
Never has. In very simple terms, it was always about standardizing OS interfaces for variant Unices. Over time, it’s moved on to be aligned with POSIX.
Terry Lambert has written about the work he did to make Mac OS X UNIX compliant: https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix...
I don't know how much it costs for the Open Group to certify an OS as UNIX compliant (if anything).
A lot of the time, things are compliant in most of the common stuff, but they might not implement all of UNIX or POSIX. Close isn't compliant, but it's enough that most people don't care. For example, do you care if your Linux disto comes with the `pax` command? Or do you just use `tar`?
Apple had started calling OS X UNIX and was being sued for calling it UNIX when it wasn't actually UNIX. They decided it'd be cheaper to do the work to make OS X UNIX compliant than to deal with the lawsuit and that's what they did. BSDs never cared about calling themselves UNIX so they never went into the nitty gritty of making themselves UNIX compliant.
https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....
This lawsuit happened (1992-1994) when Linux was in its infancy (Linus Torvalds started work on Linux in 1991). Had the future of BSD not been so uncertain during this lawsuit, it is quite possible that some derivative of BSD would be the dominant FOSS operating system today instead of Linux.
The BSD license, while appealing to corporations due to its permissive nature, allows proprietary entities to incorporate the code into their products without giving back to the community. This has happened multiple times, with examples like Apple's Darwin, NetApp, QNAP, and Sony's PlayStation systems.
The GPL, on the other hand, attracted early contributors because it ensured that their work would remain open and shared with the world, rather than being exploited for profit.
Who is interested about such certification?
You could map Cmd to Ctrl but that only fixes copy/paste, but now it will send a SIGTERM to the terminal on Cmd-C now, which means that’s still a pain.
You could write some custom keyboard driver that intelligently maps the command keys to the right keys the app expects, dynamically based on some rules, but that sounds horribly brittle and likely unworkable.
Also, on decent keyboards (not necessarily expensive) you can remap the keys anyway.
I really really wish I could have this behavior on Linux… but alas, every app under the sun chooses its own copy/paste shortcut and they all use ctrl+C/V by convention so you can’t configure it globally without rewriting every app (ok maybe you could narrow it down to a few GUI libraries like gtk/qt/etc but it’s still a huge undertaking.)
I’d settle for “ctrl-c is copy if text is selected, SIGTERM otherwise” logic, which I think Windows’s console uses, but none of the Linux terminals I’ve tried support that. I’m left with ctrl-shift-C for copy, which leaks into my muscle memory, then I accidentally use that combo in the web browser too and it opens developer tools or something. So annoying.
This lack of functionality has been in existence since Mac OS X's inception. It's the reason why a cross-platform software _always_ has to support both select() and poll() to check if a user is typing on the terminal -- select() just for Mac OS X, and poll() for every other system. Wouldn't it be nice if we could standardise on poll()?
Compare what macOS manpages say:
https://developer.apple.com/library/archive/documentation/Sy...
> BUGS: The poll() system call currently does not support devices.
with the requirements 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.
Is the bug fixed in macOS 15 or is this certification yet another load of horseshit?
But that was easy enough to fix. ¯\_(ツ)_/¯
Why did they claim it? They’re trying to justify the $475 million they already spent merging with NeXT? Early Mac OS X stuff wasn’t well received, especially their early server product based on Rhapsody.