Even those points can be argued around in various ways, so they're not even that clear-cut.
> uniform, comprehensive, robust package management, including for the system software
Every Linux distribution has its own package manager, so that somewhat fails on the 'uniform' point. Package management for system and apps being shared (comprehensive) is an arguable point as well, and 'robust' seems to not be the default on more traditional Linux distributions.
The approach seen in for example Fedora Atomic matches the macOS approach a lot more, including rollback and consistency, but also splitting the system image, overlays, and user apps.
> GNU coreutils
Not all Linux distributions have these, either, busybox distros seem fairly common these days (and offer most the popular switches you'd see with GNU utilities).
In addition, of course, the GNU utilities run under any UNIX-like, so if you do need any of the convenience switches you're used too, they exist anywhere as well.
Again, of course, subjective.
> good filesystems
APFS seems 'better' than the ext* default seen on most Linux distributions, and has had less of a history of 'random corruption' than early btrfs.
> 'root is root', ...
Red Hat-like distributions (and even Ubuntu) seem to by-default enable some kernel security module, which have the same effect.
The implicit UID 0 bypass is nasty for security.
> lots of .. terminal emulators
I'm not a picky terminal user, but macOS Terminal.app nowadays seems to match, say, gnome-terminal or Konsole quite well in behavior.
Perhaps it doesn't support some fancy feature set, but I'm not sure if the main DEs do either.
> some choice in desktop experience
Valid point. However, if you prefer something as uniform as the macOS experience, you can't get that on generic freedesktop Linux.
> popular apps don't just entirely stop working
Depends. The typical Linux distribution has a nasty ABI as well, often only guaranteeing source compatibility.
This is indeed often easier to work around even for binary-only Linux apps (on a multilib amd64 system, you can usually run some libc5 app from the late 90s fine. on macOS, this is 4 CPU architectures ago and you won't even stand a chance).
> pretty much everything is discoverable and configurable if you're determined
Same goes for macOS and even Windows. Reverse engineering is a thing that can be done with sufficient determination, and in many legislations has exemptions for these kinds of use cases.
macOS and Windows also offer symbol names for a fair amount of OS components, it's just perhaps a little more work than 'grep the source code for a flag'.
In the end, however, it's all a matter of tradeoffs and what you're used to (i.e. won't have to waste time learning before being able to get work done), and if you're used to something that varies from the default of any system, this is less and less likely with macOS or Windows.
> Every Linux distribution has its own package manager, so that somewhat fails on the 'uniform' point.
No, what I mean is that on every given system, you can manage all software on the system with a single tool, whether it's an application or a system component. Everything shares an installation mechanism and an update process— uniform in that sense.
> 'robust' seems to not be the default on more traditional Linux distributions.
The traditional ones are not robust to things like pulling the power during package installation, but their behavior is predictable and they're capable of reliably doing the basics, which is something Linux users will painfully miss any time they're on macOS or Windows.
> The approach seen in for example Fedora Atomic matches the macOS approach a lot more, including rollback and consistency, but also splitting the system image, overlays, and user apps.
I think this is an approach that has a ton of value for many users, and that kind of separation is common among Unices. Using just one tool for everything has always been a Linux weirdness. I like it, but one of the consequences that sucks for casual users or newcomers is that you're effectively always managing the whole system; there's no such thing as 'just installing $APPLICATION', because all installations are interconnected through the global web of dependencies. It's kind of cool but it's also kind of a mess, and it leads to the possibility of accidentally uninstalling your desktop environment when you mash the yes button trying to install Steam.
I think the split system approach is good because it can end that type of problem, but I think having the base system still be modular and flexible is valuable. Fedora Silverblue is like this and IIRC FreeBSD is actually like this these days, since the base system has also been packaged. SteamOS is famously like this, as well, where Steam is essentially the package manager that sits atop the base system which is packaged but which you have to 'unlock'.
Upgrading the macOS base system is not atomic, though. I know because I once bricked a Mac Mini that I thought was stuck during an OS update by unplugging it. :)
A macOS à la carte where you maintained the separation between the base system and user packages but the base system was still parceled out into individual packages would be really cool. I'd be interested in playing with that for sure.
> > good filesystems
> APFS seems 'better' than the ext* default seen on most Linux distributions, and has had less of a history of 'random corruption' than early btrfs.
Yeah, what I mean here is that because Linux is such a player in the datacenter, even desktop Linux users have choices of really excellent filesystems available.
APFS is basically just a backend for Time Machine. You can't even take persistent or named snapshots that you know won't be garbage collected later, never mind the performance of filesystems like ext4 and Xfs or the interesting features of a BTRFS or ZFS.
APFS doesn't even support transparent compression, either, which is just baffling to me on 2022.
Once the OpenZFS port for Mac matures, this situation could get a lot better, and that would be awesome.
> > pretty much everything is discoverable and configurable if you're determined
> Same goes for macOS and even Windows. Reverse engineering is a thing that can be done with sufficient determination, and in many legislations has exemptions for these kinds of use cases.
There's something really depressing to me about having to spend most of my time on a platform that's so actively hostile to me that getting simple behaviors I want is a matter of reverse engineering.
----
I think I pretty much agree with everything else :)
> uniform, comprehensive, robust package management, including for the system software
Every Linux distribution has its own package manager, so that somewhat fails on the 'uniform' point. Package management for system and apps being shared (comprehensive) is an arguable point as well, and 'robust' seems to not be the default on more traditional Linux distributions.
The approach seen in for example Fedora Atomic matches the macOS approach a lot more, including rollback and consistency, but also splitting the system image, overlays, and user apps.
> GNU coreutils
Not all Linux distributions have these, either, busybox distros seem fairly common these days (and offer most the popular switches you'd see with GNU utilities).
In addition, of course, the GNU utilities run under any UNIX-like, so if you do need any of the convenience switches you're used too, they exist anywhere as well.
Again, of course, subjective.
> good filesystems
APFS seems 'better' than the ext* default seen on most Linux distributions, and has had less of a history of 'random corruption' than early btrfs.
> 'root is root', ...
Red Hat-like distributions (and even Ubuntu) seem to by-default enable some kernel security module, which have the same effect.
The implicit UID 0 bypass is nasty for security.
> lots of .. terminal emulators
I'm not a picky terminal user, but macOS Terminal.app nowadays seems to match, say, gnome-terminal or Konsole quite well in behavior.
Perhaps it doesn't support some fancy feature set, but I'm not sure if the main DEs do either.
> some choice in desktop experience
Valid point. However, if you prefer something as uniform as the macOS experience, you can't get that on generic freedesktop Linux.
> popular apps don't just entirely stop working
Depends. The typical Linux distribution has a nasty ABI as well, often only guaranteeing source compatibility.
This is indeed often easier to work around even for binary-only Linux apps (on a multilib amd64 system, you can usually run some libc5 app from the late 90s fine. on macOS, this is 4 CPU architectures ago and you won't even stand a chance).
> pretty much everything is discoverable and configurable if you're determined
Same goes for macOS and even Windows. Reverse engineering is a thing that can be done with sufficient determination, and in many legislations has exemptions for these kinds of use cases.
macOS and Windows also offer symbol names for a fair amount of OS components, it's just perhaps a little more work than 'grep the source code for a flag'.
In the end, however, it's all a matter of tradeoffs and what you're used to (i.e. won't have to waste time learning before being able to get work done), and if you're used to something that varies from the default of any system, this is less and less likely with macOS or Windows.