Live data from Hacker News

Our audit of Homebrew

blog.trailofbits.com

71–80 of 205 posts

Re: Our audit of Homebrew

#71
Before moving to Nix, I was using MacPorts since Homebrew had some...eccentric behavior at the time (didn't work with multi-user setups, owned your /usr/local, lots of "works on my machine" problems from auto-updating and lack of version control, ...). One thing that has always felt insecure about Homebrew to me was the ability to use GitHub (not Git) URLs as ad-hoc packages. I wonder if that is how TOB-BREW-13 worked? That feature of Homebrew has always sounded like a security incident waiting to happen.

In any case, I'd be interested in seeing an audit of Nix on Mac OS. Especially if there is a flaw in how `nix develop` and related commands work.

Re: Our audit of Homebrew

#74

If macs supported PKGBUILDs like Pacman with a similar level of performance and there were correctly maintained packages for core programs I'd feel like using a mac would have a lot less compromises for convenience. Homebrew is great and the formulae are maintained really well but the simplicity of PKGBUILDS, the fast syncing, and lack of cognitive burden of recalling multiple arguments/flags for package managers mak…

There have been a few attempts at this. I think some of them may even be working.

Re: Our audit of Homebrew

#75

Earlier quoted context omitted.

I've been using MacPorts for as long as I've wanted a macOS package manager, and it's been working very well for me.

Anyone know why Homebrew overtook MacPorts? I only have a vague recollection of a Rails colleague pushing me to switch circa 2013 or so and haven't given it much thought since, but it (MacPorts) seemed to be similarly ubiquitous prior.

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.

Re: Our audit of Homebrew

#77
post #17

Earlier quoted context omitted.

When I've had to use a Mac, I've used nix to good success. I'm actually surprised how well it worked; I was able to basically just use the same config I use on Linux, removing just the few Linux-specific packages.

Do you not use many packages and only strictly use FOSS tooling? I have a large and growing list of packages that have to be managed in Homebrew still because the package is one of the following: 1. Not available at all in nixpkgs (e.g. Docker Desktop, BetterTouchTool, etc) 2. In nixpkgs, but completely broken or missing some architecture support (e.g. Firefox) 3. Actually available and somewhat functional in nixpkgs…

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

Re: Our audit of Homebrew

#78

Apple should have been the one funding the audit.

Apple should have written it themselves. It's embarrassing that they didn't. Nonprofit Linux distros with one-millionth the resources manage to write package managers and run repos, and then with MacOS, Apple gives you diddly-squat.

Re: Our audit of Homebrew

#79
post #38

Earlier quoted context omitted.

I cannot reply to your top comment for some reason, so asking here: What is your personal recommendation for Mac users? Would you suggest a different package manager and, if so, which?

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.

My dumb brain had to read it 3 times before realizing that by saying "the findings were not inconsistent with what I'd expect" you meant "the findings _were_ consistent with what I'd expect"

Re: Our audit of Homebrew

#80

Earlier quoted context omitted.

I've been using MacPorts for as long as I've wanted a macOS package manager, and it's been working very well for me.

Anyone know why Homebrew overtook MacPorts? I only have a vague recollection of a Rails colleague pushing me to switch circa 2013 or so and haven't given it much thought since, but it (MacPorts) seemed to be similarly ubiquitous prior.

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.
Post reply on HN