Live data from Hacker News

Homebrew 4.0.0

brew.sh

331–340 of 403 posts

Re: Homebrew 4.0.0

#331

On macOS, has anyone moved from/to MacPorts to/from Homebrew? Why did you move? What are the pros and cons of each system?

I switched from Homebrew to Macports, although I may switch back. Basically, Homebrew will completely crap out on you if you are ever more than two macOS versions out of date. The brew people simply don't keep the older bottles around for those versions of macOS. I think there's a grace period of like one extra version, but eventually they will delete it. Once that happens, your system is hosed if you ever need to in…

> it's not on Macports, what do you do?

Portfiles are definitely a little more outré than brew's Ruby, but I've found it's not too hard to make one for a tool by starting from another similar existing port. You get the contents of the example one with `port cat $existing_tool`, tweak it, and then add it to a local port repo: https://guide.macports.org/chunked/development.local-reposit... And then you can just `sudo port install $new_tool`

Re: Homebrew 4.0.0

#332
post #44

Reminder that nothing in Homebrew has any signing or attempt at supply chain integrity. Now that they are moving away from clients using git, so even git commit signing is off the table now. When you install brew you are giving hundreds of people (or anyone who has access to their Github accounts) full remote code execution on your machine. Never ever use brew on a machine you use to access production.

Don't install untrusted code on your machine or your machine may do untrusted things. If you're worried about it, compile your own builds.

> If you're worried about it, compile your own builds.

You forgot an important part: If you're worried about it, compile your own builds, and read and fully audit all the code before compiling. Then upon every update, read and audit all the changes. I believe this is infeasible even for the tech giants.

Re: Homebrew 4.0.0

#333
post #198

Earlier quoted context omitted.

A lot of Homebrew packages are pre-compiled binaries ("bottles" produced by Homebrew) that are pretty much just downloaded and untarred onto your system. The Homebrew formulas' are what's used to produce those binaries, or - if there's no pre-compiled one available - that's when it's compiled live on your system. Seems like a decent tradeoff, as otherwise installing (say) Qt could take an hour+, since that's a bit of…

The problem is that every time you install something it will update a gazillion dependencies because there is a minor version difference in a library I don't even use. And of course I did not ask for those binaries to be upgraded. When I do a yum install, 99% of the cases it just add the package I need. And won't mess with my dev tools.

I believe you need to set the envvar HOMEBREW_NO_AUTO_UPDATE to avoid that problem.

Re: Homebrew 4.0.0

#334
post #319

On macOS, has anyone moved from/to MacPorts to/from Homebrew? Why did you move? What are the pros and cons of each system?

Switched to MacPorts on an older machine which Homebrew dropped support for (and deleted all prebuilt binaries) While neither is great as a package manager, especiall with their dependency resolution, here are a few pros&cons: Apps: ++ Brew has a much more up-to-date collection, also more non-source binaries. App customization: + Port, Brew dropped support for custom install flags a while ago + Brew you can setup aut…

> Space: + Brew. Both waste it with their poor package repository architecture, but with Brew you can at least delete the repo after the first install and use their API to download updates.

BTW, with this release the Homebrew uses the API by default and doesn't clone the repos unless necessary.

Re: Homebrew 4.0.0

#336
post #9

Earlier quoted context omitted.

You know, as the law requires in the EU

I don't think the law is applicable to a software project. For example, GDPR is applicable to organisations that are processing personal data. I'm fairly sure that an open-source piece of code that you download and install yourself isn't in scope.

The GDPR applies to anything that collected PII about EU citizens.

Re: Homebrew 4.0.0

#337

Earlier quoted context omitted.

It does that by making a global location (/usr/local) user-owned, which I'd say is much worse.

Several years ago, when the read-only-system OS changes happened, they switched to /opt/homebrew.

By default, Homebrew requires world-writeable location in the PATH (doesn't matter if it's /opt/homebrew or /usr/local). In my opinion, this isn't a sensible choice.

Homebrew, as the name implies, was built for hobbists with little regards for security. Not a problem for many, but it does make it incompatible with a corporate environment.

Re: Homebrew 4.0.0

#340
post #271

Earlier quoted context omitted.

devenv is super promising, but I do find it a bit intrusive that Nix creates a separate volume for its store on Mac OS

I was bummed out by that too initially.But it's kind of inevitable with root not writable on the latest macOS releases and needing the store to be under /nix.

They could move the store. Like Homebrew.
Post reply on HN