Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Our audit of Homebrew

blog.trailofbits.com

Post reply on HN
Print view View original

41–50 of 205 posts

Re: Our audit of Homebrew

#41

Post by SOLAR_FIELDS »

paholg wrote: post #17
jmbwell wrote: post #10

With so many other package managers available, I often wish something else was the de facto package manager on macOS. Something like pkgsrc, which follows conventions much better and is thereby much easier to manage.

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, but some significant features don't work because of code signing requirements and needing to be managed in the Applications folder (e.g. 1Password)

Quite a few tools do in fact work well with nix on Mac. Especially if it's FOSS and/or a cli-only based tool. And for FOSS tooling such as Firefox, there is often a convoluted workaround (I'm currently using `github:bandithedoge/nixpkgs-firefox-darwin`). And of course you can always package it yourself by doing things The Hard Way.

But the platform is still quite a ways away from being able to be used as a daily driver on Mac without Homebrew.

Re: Our audit of Homebrew

#42

Post by ggm »

jagged-chisel wrote: post #39
marxisttemp wrote: post #36

MacPorts is always waiting for you with more packages, a better design, and Jordan Hubbard’s history with BSD/Apple :)

so many projects release only formulas for homebrew. I keep both and try to use McPorts first.

Most homebrew users started in macports, or fink. Very few I talk to (admittedly not many and curmugeons) want to go back.

Re: Our audit of Homebrew

#44

Post by brandall10 »

CaliforniaKarl wrote: post #16
jmbwell wrote: post #10

With so many other package managers available, I often wish something else was the de facto package manager on macOS. Something like pkgsrc, which follows conventions much better and is thereby much easier to manage.

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.

Re: Our audit of Homebrew

#45

Post by eduction »

ggm wrote: post #42
jagged-chisel wrote: post #39

Earlier quoted context omitted.

so many projects release only formulas for homebrew. I keep both and try to use McPorts first.

Most homebrew users started in macports, or fink. Very few I talk to (admittedly not many and curmugeons) want to go back.

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.

Re: Our audit of Homebrew

#46

Post by llimllib »

brandall10 wrote: post #44
CaliforniaKarl wrote: post #16

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.

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

Re: Our audit of Homebrew

#47

Post by dmd »

ggm wrote: post #42
jagged-chisel wrote: post #39

Earlier quoted context omitted.

so many projects release only formulas for homebrew. I keep both and try to use McPorts first.

Most homebrew users started in macports, or fink. Very few I talk to (admittedly not many and curmugeons) want to go back.

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.

Re: Our audit of Homebrew

#48

Post by parhamn »

eduction wrote: post #45
ggm wrote: post #42

Earlier quoted context omitted.

Most homebrew users started in macports, or fink. Very few I talk to (admittedly not many and curmugeons) want to go back.

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.

> Key difference is Mac ports keeps its tree separate in /opt

What do you mean by this? brew has been linking from /opt/homebrew for years now.

Re: Our audit of Homebrew

#49

Post by 1123581321 »

brandall10 wrote: post #44
CaliforniaKarl wrote: post #16

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.

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.

Re: Our audit of Homebrew

#50

Post by RulerOf »

Alifatisk wrote: post #12
woodruffw wrote: post #3

Earlier quoted context omitted.

Yep. We use the TOB-$PRODUCT-$XXXX convention for our audit findings, where $PRODUCT is the target under audit and $XXXX is a unique incrementing counter for each finding. (As far as I know, a lot of audit firms do similar things.)

First time seeing TOB being used honestly, it would’ve helped saying something along the lines of ”Trait of Bits (TOB from now on)”

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