> 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 :)