Live data from Hacker News

Our audit of Homebrew

blog.trailofbits.com

91–100 of 205 posts

Re: Our audit of Homebrew

#91

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.

What a nonsensical conclusion. Homebrew existing is no reason for Apple to do replicate that trainwreck.

Re: Our audit of Homebrew

#92

Earlier quoted context omitted.

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"

One should try to avoid using double negatives in both speech and programming to make intent more obvious ;-)

Re: Our audit of Homebrew

#93

The amount of value returned to the Apple ecosystem through brew is remarkable and while this post makes me even more in awe of the care that goes towards the community, I'm sad that one of the richest companies in the world isn't giving more back.

[deleted]

Re: Our audit of Homebrew

#96

I ditched `brew` for `nix` a while back and while the TUI could be more end-user-friendly (to the point that I wrote a wrapper called "ixnay" just so I could do "ixnay install " as easily as with brew, https://github.com/pmarreck/ixnay ), the overall guarantees make it worth it.

I also find the nix command line annoying. I'll give this a try. I like the embedded `#help` documentation!

Re: Our audit of Homebrew

#97

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…

Is MacPorts not the same? Genuinely asking.

Re: Our audit of Homebrew

#98
post #87
post #84

Earlier quoted context omitted.

Apple would certainly favor macports over that rubbish ruby thing. Ports are from FreeBSD, MacOS is from FreeBSD.

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

You should read https://en.wikipedia.org/wiki/MacPorts#History. But to answer your question: why not? Apple employs thousands of software engineers.

Re: Our audit of Homebrew

#99

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

I was wondering recently if there are any downsides of using MacPorts and homebrew for different packages on the same system. Homebrew excels at keeping all my single binary CLI tools up to date, but I don't particularly like how it forces me to upgrade more complex software packages like MySQL or FFmpeg constantly.

There is also the issue, that my iMac is stuck on Ventura, and soon won't be supported by homebrew anymore.

Re: Our audit of Homebrew

#100
post #68

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/

Workbrew wraps a vanilla, unmodified Homebrew on Macs running it under a ‘workbrew’ user for user privilege separation and better multi-user support.
Post reply on HN