Our audit of Homebrew

When I started using a Mac in 2009, MacPorts, Fink (and I think there was another I can't recall the name) simply wouldn't work for me. They would take very long to build what I wanted, there weren't nearly as many packages as was in Debian/Ubuntu, and many were old versions. Worse, many build attempts would just fail.

In that scenario, brew worked like a charm. It was quick, had most or even more packages than Debian/Ubuntu and they were newer. Failure to install was rare.

Then, Apple started yearly release of OS X, and that both broke brew and my system hard, so I started investigating and found out about the many "shortcuts" that brew took and how it violated systems components. I was dismayed, and abandoned brew for good.

So, I stood a period where I would use many of my tools inside a Ubuntu VM, until probably 2013-2014, when for some reason I tried again MacPorts, and I don't know why, but that time it was much more reliable, and because of Apple's insane atm SSDs with 2 GB/s bandwidth, install became quick enough. Packages were still somewhat lagging behind in available versions, but the variety of them kinda reached the levels of what was in Debian/Ubuntu, so it was good enough for me.

Then, the killer feature, I found out about macports variants and selectors, which I find the most awesome thing to this date in package managers (I haven't tried nix, still, it might be magnitude better in that regard). No needing to use rvm, pyenv, custom installs of gcc messing with make/autotools, and the only sane way of compiling various Haskell projects (before haskell-stack).

MacPorts was slower (bringing in its own dependencies for everything meant longer build steps) and required sudo more. There were some annoying fiddly parts that made it seem like the homebrew users around you were having more fun exploring packages.

It was also exciting how many packages and casks were in homebrew and it was easy to make your own.

Also, back then there were lots of people experiencing package managers for the first time and they took to homebrew easily.

Then so many projects started to publish brew install links as a way to get started; homebrew felt like a default.

Now, with our faster computers, more space, and more packages installed, and macports shipping more binaries and using its own normal user, macports' duplication of dependencies looks more like an advantage than a disadvantage. And because homebrew taught so many people how to use package managers, macports is not their first so easier to start using.

People like beer but also Homebrew had a cute site and made ports simpler than MacPorts. Turns out complexity was maybe not unwarranted. I was among first adopters of brew but now I port for years

I guess MacPorts was (and is) geared more towards users with some proper UNIX or BSD background, e.g. people coming from FreeBSD.

Whereas Homebrew targets the typical Mac user who might need a CLI application occasionally, i.e. someone looking for simplicity, without being too technically savvy.

The latter group certainly makes up a much bigger share of users on macOS, especially nowadays.

Here's my guess.

Homebrew had at least these things going for it:

  - it has always had a strong emphasis on presenting a simple, clean, pleasant, pretty, playful UI and executed that well
  - when it came out, source-based package managers for macOS generally didn't have any binary caching mechanisms, so compile time mattered
    - Homebrew's embrace of the base system as opposed to bringing its own dependencies bought it greater reuse at the cost of robustness, driving down total time to install many packages
  - the language that `brew` and its packages were written in was trendy at thw time as well as pre-installed on macOS, which made them instantly accessible to huge numbers of web developers
    - the older macOS package managers generally drew on traditions and tooling from the Linux world (e.g., Fink, with Debian tooling) or the wider Unix world (e.g., MacPorts and various *BSD ports systems and packages written in some Tcl IIRC).

Here’s why I switched early on in homebrew’s life from ports

- brew had and has many more packages available

- brew updates versions more quickly

- brew uses much more simple paths that fit my brain better

- brew has a pleasing simplicity

At the point I switched from MacPorts to Homebrew, homebrew just worked more reliably in my experience. It installed things quicker and with fewer build/install failures. i don't know enough about what was going on under the hood to have any theory as to why this was my experience; I don't want to know what's going on under the hood, I just want to type `install whatever`, and have it work.

this was a while back, in the Gentoo Linux heyday, so it was popular to compile things, except that this was when computers were slow, so that meant waiting for compiles. the problem with macports was that (iirc, it's been a while) it compiled its own version of Python instead of just using the system python, which also broke sometimes. and then you had to compile all that shit again. brew won out because it was faster, and didn't duplicate redundant shit for no perceived reasom.

Same here.

I recently tried out mac-app-util¹, which fixes some of the usual pain with GUI apps. In conjunction with brew-nix², it looks like it might be most of what I'll need to move away from having Nix manage Homebrew for me.

I don't use very many GUI apps so now that the installation piece is taken care of, I can just package everything I use if it really comes down to it. That'd be worth it for me just to get rid of the painfully slow `brew` invocations that lurk in my activation scripts.

--

1: https://github.com/hraban/mac-app-util

2: https://github.com/BatteredBunny/brew-nix

Huh, interesting. I did primarily use FOSS and CLI applications. It's been a couple years, so I don't remember what exactly I used it for. I probably installed Docker Desktop via whatever method docker recommends, and I'm not sure about Firefox.

For alacrity, I remember it being annoying to integrate into Mac's launcher, but it otherwise worked.

Pretty much everything else was programming-related and just worked.

If you want graphical apps to be handled by nix on macos, you might be interested in <https://github.com/BatteredBunny/brew-nix>. nixpkgs does not package macos sandboxed apps AFAIK, that means typically only cli utilities, libraries and development tools only work.

Given that I did the audit, I don’t think it’s appropriate for me to offer an endorsement (or a negative endorsement) in this context. What I’ll say is this: the findings on Homebrew were not inconsistent with what I’d expect to find on any similarly sized userspace package manager that serves its own binary builds.

I use nix on both mac and linux, also on CI where homebrew is especially brittle

Other companies do similar things. Red Hat creates RHSA-YYYY:XXXX for example, like this one for Log4Shell: https://access.redhat.com/errata/RHSA-2022:0442

Key difference is Mac ports keeps its tree separate in /opt. This means things take longer initially to install because it can’t just leverage system stuff already there. Upside is greater reliability because it doesn’t have to worry about a system update changing its dependencies.

I prefer the greater reliability of macports.

That was probably true in homebrew’s first year. At this point I would be shocked if more than a fraction of a percent of homebrew users have ever even heard of macports or fink.

On an old Macbook I keep around for various rare offline tasks, I actually did go back to MacPorts from Homebrew. Chief reason being: Homebrew doesn't support old versions of the OS so I was SOL trying to install a new package on it. The backwards compatibility is a nice feature!

My current machine is also not on the latest so I wonder if an attempt to brew update would nag me now...

- too much sudo friction

- homebrew's design of having a single app's folder is better, e.g., can use your basic file manager to see the total size

- updates requiring manual inervention

- fewer/less updated packages (mabye due to the previous deficiency?)

- large duplicate database wasting space (and think it's even uncompressed) (brew got better when it moved to it API)

Then why did Apple hire the creator of Homebrew to work on the package manager for Swift?

That is provably false from so many angles.

* Apple has no aversion to Ruby, and on the contrary has multiple developers pushing for it. They themselves had MacRuby, a project that allowed one to create Mac OS X (at the time) applications with Ruby.¹

* The reason there’s even an Xcode command line tools package available officially from Apple is because of Homebrew. A third-party made it first by extracting the necessary bits and then Apple officially supported it.²

* There’s a liaison between Homebrew and Apple, who helped during the Intel to Apple Silicon transition.³

¹ https://web.archive.org/web/20100908131627/http://developer....

² I know this from a reliable source and it is public information, but it was so long ago it’s hard to find.

³ The official Homebrew Twitter account tweeted about this at the time. I no longer have a Twitter account so can’t dig it up.

No need to call someone’s free open source project “rubbish”.

I’m not sure.

Back in the day Apple marketed macOS as a serious Unix system for scientists and engineers boasting about NASA’s use of it.

I think if Apple aspired to lockdown general purpose computing they would push the ipad pro range with more models and slowly kill off the Mac but they’re not doing that.

IMO, it's just counter to what Apple aspires MacOS to be.

Every OS wants to be attractive to developers. Apple has a long history of underdelivering this core proposition. To me it's an odd situation to reason about - look at Apple's dev conferences and then look at what it's like on the ground in dev's reality.

It would be (or at least have) a command-line utility like rpm, npm, apt, or pacman. That's necessary for it to integrate well with various installation scripts. So you wouldn't have to use a UI at all, especially if it's bad.

I thought it was clear from my comment that I was suggesting Apple would do it better. Think of how useful something like apt, npm, or pip is, and then realize that MacOS has no in-house equivalent.

I’ve had a few build pipelines break over the years because of a watchman dependency. IIRC it was usually an issue with an npm library depending on watchman but downloading a binary that was incompatible with the architecture or implemented the wrong syscalls for the operating system.

I don't think that's accurate—homebrew specifically says that it only uses the .linuxbrew directory when a formula contains a hardcoded path (which it scans for), and only if you choose not to install it from source.

So, based on the responses from the maintainers, for the .linuxbrew directory to be used, you have to satisfy 2 conditions:

1. you have to be installing one of the ~10% of formula that isn't trivially relocatable.

2. you have to be using a precompiled binary (which it seems like homebrew is smart enough to not do if condition #1 fails and you're not using sudo)

All the Nix commands that take an 'installable' can take GitHub URLs. For instance:

    $ nix run github:NixOS/nixpkgs#hello
    Hello world!

But to find out what the flake exposes at all, reading the flake (or its documentation) is pretty much necessary.

If the flake exposes default packages or apps, then you do not need to provide a flake attribute:

    $ nix run github:NixOS/nixpkgs
    error: flake 'github:NixOS/nixpkgs' does not provide attribute 'apps.aarch64-darwin.default', 'defaultApp.aarch64-darwin', 'packages.aarch64-darwin.default' or 'defaultPackage.aarch64-darwin'

    $ nix run github:kamadorueda/alejandra

EDIT: For what it's worth, I think this feature can be useful sometimes, but it does also suffer from the same typosquatting problems as we see in other ecosystems.

Oh this looks pretty cool. I started using Docker a while ago for dev projects to avoid package/language version hell, but sometimes its a bit overkill

Also for that case, I don't think we have any clue who the guy is. Name just not meaning anything. Or anyone has any link to a formal trace to the origin?