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