If it was the exactly same thing it would have been called Linux :)

You can bend the experience the way you like, you don't have to use it as-is. For example, homebrew can take care of the few of the complaints here.

By the way, I thought that apps stopping working randomly was a Linux feature? Then you dive in to to fix it, not really an experience I miss.

Also, hunting down software for Ubuntu 14.04 or 18.04 because something that works for one doesn't work for the other is a Linux experience. Often you don't have software that simply works on "Linux", you need to find it for specific distro and even specific distro version or compile it from source. The compiling from source often means you need to install the tooling and libraries for that specific version. Then you will have distro and version specific instructions to install, configure and run the thing.

Linux is a horrible experience for people who see their computer as tools and don't really like to manage it and want to spend their energy on using that tool to do other things(like designing apps, studying some data, making videos etc).

Anyway, it boils down to your preferences.

> For example, homebrew can take care of the few of the complaints here.

Not really. Homebrew doesn't manage the operating system (which I understand is a desirable kind of separation for some users), and it's also just not comparable to Linux package managers in its technical aspects. The result is that it's just not as reliable, predictable, fast, or complete as virtually any distro package managers on Linux.

> By the way, I thought that apps stopping working randomly was a Linux feature? Then you dive in to to fix it, not really an experience I miss.

Apple takes a pretty radical position with respect to backwards compatibility on macOS, and this has some benefits for Apple as well as developers of greenfield projects on macOS, but it does have some downsides. One issue related to those downsides is that a huge proportion of macOS software aimed at power users whose purpose is to refine or extend the desktop experience relies on undocumented or unsupported APIs to achieve its functionality, because that's all that's available to that end. With every macOS release, such APIs are ruthlessly culled, and at least a few apps are either left without replacement or have to be completely rewritten. (The most annoying one which affected me when I was a daily macOS user was maybe the forced obsolescence of Karabiner, for example.) There's really nothing comparable on Linux, for a range of reasons.

> Also, hunting down software for Ubuntu 14.04 or 18.04 because something that works for one doesn't work for the other is a Linux experience.

That kind of thing can be a serious frustration with proprietary software that only officially targets a specific Ubuntu LTS release, and it used to be especially painful before the the availability of containerized app platforms like Flatpak and Snap. If your work requires you to use software that doesn't support your OS, that is definitely a problem.

> Often you don't have software that simply works on "Linux", you need to find it for specific distro and even specific distro version or compile it from source.

As they say, Linux is not an operating system. Distros are operating systems. Fragmentation is just the obverse side of choice here, but when the Linux userbase as a whole is so small, I get feeling frustrated by that.

As for building software that's unpackaged on your distro of choice: per-distro variations in build instructions are generally not an issue unless you're just following those instructions more or less blindly or by rote. Packaging software can be annoying on very niche distros with small repos just because you have to do it frequently, but it's pretty rare and not very hard to do for the vast majority of software. To me, it doesn't make much sense to choose a platform with inferior tools just because some software you like might be pre-packaged for it, when you can just choose a platform whose package management tooling you actually like, and package the few outstanding odds and ends you need on the platform. (This is generally how I think about choice of distro.)

> Linux is a horrible experience for people who see their computer as tools and don't really like to manage it and want to spend their energy on using that tool to do other things(like designing apps, studying some data, making videos etc).

I think this is really overstated and stereotyped. Even though I'm a Plasma user who has strong preferences for particular distros, you can stick me on any major Linux distro with any desktop environment, and even largely sticking to the defaults there will still leave me feeling much more at home than I can on macOS. It's not about time spent configuring or customizing, and it's not just about a compulsion to tinker, either. It's different, even if you stick to defaults and even across distros. It's a lot of little things but it really adda up to a whole different vibe.

I also want to say that I think the metaphor is misplaced. An OS is not a tool like a hammer is a tool, because it's a whole environment rather than an object. Your workstation OS isn't like a screwdriver or even like a toolbox. It's like your whole garage, your whole studio, the whole warehouse, the whole factory floor. It may not make a lot of sense to care about customizing one specific screwdriver. But caring about being able to freely arrange your workspace is pretty natural, and macOS' differences from Linux are a genuine, substantial culture shock when you're coming from Linux workspaces that have become cozy and efficient to navigate for you.

>The result is that it's just not as reliable, predictable, fast, or complete as virtually any distro package managers on Linux

I disagree, for example pacman will happily break your system if you have any third party packages or don't use it exactly as prescribed. Not all Linux package managers are perfect or even that good.

> Not all Linux package managers are perfect or even that good.

Definitely. And the good ones are sometimes the most frustrating for their remaining imperfections! But when you compare them to package managemwmt efforts outside of Linux and free Unix distros, efforts like Homebrew or pip or NPM, there are typically lessons that Linux distro package managers have learned from each other that the others miss, to their detriment.

> for example pacman will happily break your system if you have any third party packages or don't use it exactly as prescribed.

If you care more about robustness than speed or simplicity, pacman is arguably the worst in its class. On a technical level it's still on a par with Homebrew or better, depending on what we're comparing. But it can be more painful to use in practice because of the actual role that the AUR plays in the Arch ecosystem. Arch devs' denialism about that has led to a permanent state of affairs where everyone uses the AUR and pacman ignores the dependencies of AUR packages every time it runs updates, i.e., perpetual breakage.

I'm not a fan of that design or the Arch 'blame the user for holding it wrong; after all we warned them this required manual attention' attitude. And there are better-engineered package managers available on macOS, too, like Nix and pkgsrc, too.

But the base system is still unpackaged (like in many Unix distros), and the package managers you end up needing for working on the OS are decidedly second class on the system and prone to being broken periodically by Apple. (If you follow along with Homebrew or Nixpkgs on GitHub, you can see the kinds of huge efforts they often have to go through when Apple releases a new macOS beta and it completely breaks things for them.) It's just too different to be summarized as a matter of 'like Linux but with a different GUI'.

> - uniform, comprehensive, robust package management, including for the system software

macOS uses Software Update to manage system packages, and AppStore to manage that world, and for everything else, MacPorts (if you care about your system homebrew is not an option).

> - GNU coreutils and related utilities (sed, grep, find, etc.)

macOS has a userland... you seriously can't find /usr/bin/sed in macOS? Seriously?

> - good filesystems

uh, if you actually think ext4 is any good, then I guess you just don't care about massive data loss. wtLf??!?

> - 'root is root'; no policy or other bullshit restricting what root can do by default

Always good to have unrestricted access to root for all those necessary privilege escalations. Security policy just gets in the way. Who has time to activate this and authenticate that?

> - lots of featureful, performant terminal emulators (to the point that the DE default is almost always fine)

You do realize that every single beloved terminal emulator you use on Linux most likely also runs on macOS, right?

> - some choice w/r/t desktop experience

omg. You are not required to run quartz. You can run X11 if you really want, and you can even run gnome or xfce, any window manager you want in macOS. Oh, but what you mean is because you don't know how then it can't be done.

> - popular apps don't just entirely stop working between OS releases

Because you're not aware of Linux breaking applications between releases, I guess it doesn't happen, and because upgrading system software the moment it is released is the new, state of the art sysadmin philosophy.

> - pretty much everything is discoverable and configurable if you're determined

kind of an empty observation, because this is true of all things

Stick with Linux, please. The less you know, the better off everyone else is.

I'm surprised and kind of impressed by the level of vitriol in this comment, especially given the relatively narrow focus of the comment of mine it's replying to, which didn't really consider the merits of macOS itself so much as the differences that give using it a very different vibe from using Linux for people who are used to desktop Linux.

I'm not going to reply to the ‘substance’ of your post but I will say that nothing you've written here is in fact news to me. A more curious person, or maybe just a person who is having a better day, might wonder what they're missing rather than lose their shit, when someone writes something that surprises them on the internet.

Just wanted to chime in that you're absolutely right. That comment was unnecessarily filled with hate and obsessive elitism. It's really weird that someone would take time out of their weekend to write that.

>> - 'root is root'; no policy or other bullshit restricting what root can do by default

> Always good to have unrestricted access to root for all those necessary privilege escalations. Security policy just gets in the way. Who has time to activate this and authenticate that?

On gnu/linux there’s SELinux for that, since 2001. Red Hat, that implements security very well, has had that enabled by default since forever basically.

Right, and SELinux, alternatives like AppArmor, and the various kernel hardening parameters available on Linux are things that get in your way relatively rarely. SIP is much more annoying.

And there are also configuration matters where rather than policy on what root is allowed to do per se, making things a pain in the ass is the security strategy. Like there's no way to non-interactively enable macOS' built-in SSH server without resorting to an enterprise endpoint management system.

Part of what gives the feeling that ‘root is not root’ on macOS is that you can't really administer macOS like a normal Unix system or like Linux. There's a bunch of things that require interactivity, or a cloud account logged in. There are files that are part of a normal POSIX filesystem which play a certain role in configuring Unix systems which are present on macOS, but literally just don't do anything anymore, in favor of some other format that macOS actually cares about and which is a bigger pain to edit or automate using normal Unix userland tools.

Things like creating users in a script is way more verbose on macOS than on Linux or any BSD I've seen. (The least annoying way to handle it IME is to use a wrapper that imitates NetBSD's utilities for this which is bundled in pkgsrc.)

All other complaints aside, claiming Linux has it better when it comes to “featureful, performant terminal emulators” is outright laughable. The number one thing I miss on my home Linux workstation is a good terminal emulator. Nothing in Linux land comes close to the featurfulness of iTerm2, to the point where the vast majority of Linux emulators don’t even support ligatures! Add “fast” to that and you only have one option: Kitty. Which, guess what, also runs on macOS. iTerm is generally slower than kitty, but the trade off is completely worth it, especially when you consider features like tmux CC mode which makes working on a remote system almost as transparent and reliable as working on the local system.

At the time I was on macOS, I ended up using iTerm2, but I didn't feel great about it. I understand that iTerm2 has a wealth of features, including some that are virtually unique. But I wasn't happy with iTerm2. Annoyances I can remember at the moment are:

  - it was shocking to me that getting decent performance with tmux required installing an unstable build and enabling GPU acceleration (something I never had to resort to before)
  - I had a skeptical view toward many of iTerm's unique features because
    + the whole scandal with iTerm2 leaking private data via DNS had just happened (see: https://www.bleepingcomputer.com/news/security/iterm2-leaks-everything-you-hover-in-your-terminal-via-dns-requests/ , https://gitlab.com/gnachman/iterm2/-/wikis/dnslookupissue )
    + the tmux ‘integrations’ didn't work with my tmux setup, because they require iTerm2 to launch tmux and at the time I already used a different system for managing local tmux sessions ( https://github.com/sagebind/tmux-zen ) that I liked
    + when I temporarily changed things to let iTerm2 launch tmux, I found that it broke/ignored my keybinds, which is apparently intentional -- https://gitlab.com/gnachman/iterm2/-/issues/3997
    + shell integrations always seemed almost like a layering violation to me, but also just plain didn't (and don't: https://iterm2.com/documentation-shell-integration.html ) work with normal tmux or screen sessions anyway
  - iTerm2 displayed vertical spacing with the bar characters used for drawing vertical lines in tmux incorrectly unless I went out of my way to use a special font (Hack), something I had never encountered before
  - swapping the Option and Command keys inside of iTerm2 was required for getting in-terminal Emacs keybindings to work right, but it swaps them *globally*, so that if you use either modifier in your ‘Hotkey Window’ configuration, you have to use a different key to dismiss the window than you use to summon it
    + I had to supplement my iTerm2 config with a Hammerspoon config to essentially bind summoning it and dismissing it to two different key chords, which worked but broke the animations the app features for ‘Hotkey Window’ because I was summoning it via iTerm2 but dismissing it via Hammerspoon
  - I had to modify some keycode configuration stuff to get it to act more xterm-like to get some in-terminal apps to interpret the right keybinds, and it was a more annoying, fiddly process than on terminal emulators I'm used to, which provide comprehensive profiles you can just swap between for that
  - iTerm2's configuration windows feel really disorganized, cluttered, and just messy to me compared to Konsole's
  - I didn't need some of iTerm2's special features, because I already had them implemented in my tmux config, like regex search for find-on-page and copy mode, so I didn't really have a chance to be impressed by them
  - some of iTerm2's special features, like displaying images, were then implemented only in a non-standard way, which meant I couldn't count on them on other platforms (nowadays iTerm2 and Kitty share their special image protocol, I think, plus iTerm2 supports Sixel graphics, which is really cool) and didn't really want to use things that relied on them

I feel bad about posting much negativity about iTerm2 when it is clearly such a lovingly maintained, ambitious project that serves many people well. And I understand that for people with different expectations or who don't care to have a portable, cross-platform command line environment, letting iTerm2 ‘take over’ for tools like tmux and push them to the background is an amazing feature. I also get that iTerm2 is very creative and clever about getting crufty old protocols to do things they were never originally intended to do, and that the results can be really nice sometimes.

The landscape of cross-platform terminal emulators has also changed a bit in just the past few years, because some nice terminal emulators have matured substantially.

But as someone who, a few years ago, came to macOS with a fluent, agreeable, largely terminal emulator-agnostic workflow already and just wanted ‘a fullscreen dropdown terminal that won't lag out if I have a a few noisy commands running in a tmux window’, iTerm2 was simultaneously overkill and underwhelming. On Linux, the dropdown terminals baked on the defaults of the big two DEs, Guake and Yakuake, both work just fine, as do several others that I've tried.

PS: Back then I only cared about programming ligatures in GUI Emacs, which was fine, but nowadays Konsole does have ligature support. And Wezterm is another cross-platform terminal emulator with ligature support and reasonable performance. :)

PPS: I do see an iTerm2 feature every now and then that I find myself envying until other terminal emulators I like catch up, and I'm happy to admit that the iTerm2 maintainer seems to pick up the new terminal hotness at an impressive pace. Lately it's OSC52 escapes for remote terminal Vim and Emacs sessions :)

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