Our audit of Homebrew • Hacker News Board

Re: Our audit of Homebrew

#61

Post by eduction » Wed, Jul 31, 2024, 3:08 AM UTC

parhamn wrote: post #48

eduction wrote: post #45

Earlier quoted context omitted.

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.

I did not know about the new directory practice, thanks.

From what their site says it looks like it was done this way to keep ARM native stuff separate from old intel code which can still work under Rosetta. But I don't see any indication homebrew stopped linking system libraries as a matter of course (correct me if I'm wrong).

MacPorts makes a point of not doing this. /opt/local is its own universe and dependencies can be upgraded more or less aggressively than Apple's. https://trac.macports.org/wiki/FAQ#syslibs

Re: Our audit of Homebrew

#62

Post by Cloudef » Wed, Jul 31, 2024, 3:28 AM UTC

jonahx wrote: post #38

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.)

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?

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

Re: Our audit of Homebrew

#63

Post by arandomhuman » Wed, Jul 31, 2024, 3:31 AM UTC

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 make me wish pacman just worked on macs.

Re: Our audit of Homebrew

#64

Post by CaliforniaKarl » Wed, Jul 31, 2024, 3:34 AM UTC

sizeofchar wrote: post #59

brandall10 wrote: post #44

Earlier quoted context omitted.

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.

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 Debia…

I don't know when they introduced it, but I believe MacPorts will build the common variants of the more-used packages. So, if you install a package with the default variants, you'll get a binary download instead of building from source.

But indeed; fast SSDs, parallel compilation, and modern CPUs really help!

Re: Our audit of Homebrew

#65

Post by nothrowaways » Wed, Jul 31, 2024, 3:51 AM UTC

Apple should have been the one funding the audit.

Re: Our audit of Homebrew

#66

Post by eviks » Wed, Jul 31, 2024, 3:57 AM UTC

marxisttemp wrote: post #36

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

It's also a worse design in some aspects, so not a clear winner

Re: Our audit of Homebrew

#67

Post by sohrob » Wed, Jul 31, 2024, 4:05 AM UTC

Great that there are people looking into this. I wonder if there would be similar findings were they to perform an audit on MacPorts or the Nix package manager.

Re: Our audit of Homebrew

#68

Post by eddyg » Wed, Jul 31, 2024, 4:07 AM UTC

Any idea how much impact the audit has and/or applies to Workbrew[0], their new business-oriented MDM-manageable package tool?

[0] https://workbrew.com/

Re: Our audit of Homebrew

#69

Post by KennyBlanken » Wed, Jul 31, 2024, 4:10 AM UTC

[flagged]

Re: Our audit of Homebrew

#70

Post by Cloudef » Wed, Jul 31, 2024, 4:13 AM UTC

SOLAR_FIELDS wrote: post #41

paholg wrote: 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…

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.