Homebrew's very up to date, without that cutting-edge quality risking system stability (since that's totally separate) and has an incredible number of supported packages, including tons of closed-source stuff, out of the box. No hunting down PPAs or obscure unofficial back-port packages or anything. The only Linux package managers I've seen even approach it (not match, but approach) are from bleeding-edge distros like Arch or Gentoo, but those come at a harsh stability cost since they also manage the rest of your system, including all the shared libs (ugh) and system-level packages (I gather that's the case on Arch, it sure was on Gentoo when I used it for many years, mostly because I loved Portage and OpenRC)
It's not bad, but it's not the best either. Not even close.
> including tons of closed-source stuff
Homebrew doesn't ship any proprietary formulae at all. They have a clear policy against it:
> We don’t like binary formulae
> Our policy is that formulae in the core tap (homebrew/core) must be open-source with an Debian Free Software Guidelines license and either built from source or produce cross-platform binaries (e.g. Java, Mono). Binary-only formulae should go to homebrew/cask.
> Additionally, homebrew/core formulae must also not depend on casks or any other proprietary software.
> This includes automatic installation of casks at runtime.
> Homebrew doesn't ship any proprietary formulae at all. They have a clear policy against it:
And yet, I can install Sublime Text, Slack, and others through it out of the box. I just checked a couple more, Figma's there. Microsoft Office. Steam.
You used to have to run a one-liner to enable casks (just one, not one for every damn vendor like with apt) but not anymore.
Can't edit anymore, but just wanted to say: on review that post came off as snarkier than I intended it. I just mean that, whatever the policy on including closed-source in the primary Brew repo, casks are enabled by default and don't even require a different command or any set-up anymore. From a user's perspective they're 100% as available as other packages, as soon as you install homebrew. I think the only major difference is that they don't auto-update when you do a "brew upgrade"—you have to specify the cask package you want to upgrade. Which is a good policy since a lot of those programs have their own built-in updaters anyway.
Some of this is a matter of taste, clearly. I strongly prefer having my system packages being rock solid; I can always fetch updated software for the very few cases where I want that.
However, my aversion to homebrew goes beyond taste: my experience with homebrew is rife with breakages. To be fair we were trying to use it in a CI system, which will very quickly reveal a buggy system. By contrast, apt/dnf are rock solid when used in CI.
An actual example: we tried providing our own recipe to install a particular version of libicu. This triggered an upgrade of some dependency; that triggered an upgrade of libicu to a different version than 68. The command exited with a successful status. A real package manager would have detected the package conflict and reported it, giving you resolution options, or errored out in a non-interactive terminal.
Why were we trying to pin versions in the first place? You guessed it, package breakages.
Yeah, I don't manage dev dependencies for projects in home-brew, just software for which I am a mere user. I probably wouldn't use apt and friends for those, either—not directly on my workstation anyway, maybe in some pinned-OS-version VM—unless my workstation happened to be identical to my deploy target and was guaranteed to stay that way. For a macOS build for C or C++ or anything along those lines, I'd probably vendor dependencies.
