I don't see that. Brew on Linux is a copy of dito on osx which itself was inspired by Linux package managers.

Instead of using the real deal, people generally suggest Brew because that's what they are familiar with from osx.

If you need bleeding edge of something (and don't want to build from source) we got things like flatpak, appimage directly from developers or AUR and nix and other stuff.

I'm yet to find someone proposing brew over the rest because of some new package genuinely being available only on brew only.

> we got things like flatpak, appimage directly from developers

Some people prefer timely, high-quality, well-tested bugfixes and security updates for the underlying low-level dependencies of an app.

An upstream app developer is much less likely to provide an updated flatpak mere minutes after e.g. a critical OpenSSH security fix comes out of embargo. Distro maintainers on the other hand, such as the Homebrew core maintainers, can do that. They also have security audits, see TFA, and established processes. Nothing wrong with that at all.

> and nix

That just comes down to personal preference. Some people like Nix due to the amazing level of isolation it provides, and that’s perfectly fine. Some prefer Homebrew instead because it’s easy to use and respects the FHS.

All the things we’ve discussed so far are highly subjective, come down to personal preference, and say absolutely nothing about how skilled a user is.

Core system package managers (apt etc) handle security issues quickly and in collaboration with security researchers and authorities. They have far more manpower, experience and connections than brew.

Bleeding edge is handled by rolling package managers, and these often build automatically from source as soon as a commit is tagged.

I don't see a clear reason to use brew, which does everything a little bit worse. In fact, I see it as a red flag in projects since it usually indicates lack of first class Linux support.

> They have far more manpower, experience and connections than brew.

And Homebrew’s maintainer team, in turn, has far more of all that than the average Flatpak app developer has, which your earlier comment suggested as an alternative to Homebrew.

> I see it as a red flag in projects since it usually indicates lack of first class Linux support.

In most distros, upstream projects have very little say in whether or not the distro is going to include them. It’s the distro maintainers who make that decision, and it depends on many different factors, some of them outside of the upstream project’s control, but none of them related to „first class Linux support.“

For example: is the upstream license an acceptable fit for the distro? How many dependencies does it have, and are those already available as packages in that distro? Does it make technical assumptions that clash with the distro’s assumptions? Has anyone stepped up and authored the package yet? And so on.

Never have I seen “lack of first class Linux support” as a scale-tipping argument against including a particular package in a distro.

You realise flatpak had been around almost 20 years and has a HUGE community and commercial vendors behind it?

Brew was until recently just one guy in SF.

But let's agree to disagree.

> Brew was until recently just one guy in SF.

For some very loose definition of "recently." It's been a team of multiple maintainers, spread across the world, for well over a decade at this point.