Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I use homebrew like a black box. I’m glad it exists, but I have no idea how it works and why it’s so complicated. When something breaks and Google is no help I just nuke it and start from scratch.

It’s only happened twice in more than a decade, but I still have the feeling that I was better off compiling stuff manually and cultivating a tidy /usr/local/bin like I did in early 2000s. But it’s probably rose-colored glasses and I’d definitively never take the time these days.



I think you’re right about the rose-colored nostalgia: it’s easy to forget how far behind people got on updates. I remember so many support emails where someone had hit a bug which had been patched a year earlier but never thought to install it. A couple of times where people reinvented something which had been added to PHP in the meantime because they didn’t know it was there.


But do I need the latest openSSL for local development? Seems more trouble than it should.


That’s why they keep it private by default, but the answer is often yes. There have been multiple times where a package like Python 3.10 required a newer version (1.1.1) than the OS release included (I suspect that’s also why the AWS Lambda runtime is stuck on 3.9 since it’s based on Amazon Linux 2 and that uses 1 .0).

This has settled down a bit but the big HTTPS-everywhere push last decade flushed out a ton of things which had been quietly aging in place, unnoticed until someone started depending on SNI, newer crypto suites, actually disabling deprecated versions of SSL/TLS, etc.


Maybe it’s quieted down recently after the HTTPS effort, but I feel like I need to download a whole Unix environment, down to the readline, every now and then when I just wanted to install a trivial thing.


> It’s only happened twice in more than a decade, but I still have the feeling that I was better off compiling stuff manually and cultivating a tidy /usr/local/bin like I did in early 2000s. But it’s probably rose-colored glasses and I’d definitively never take the time these days.

thats exactly what homebrew does.


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 a monster to compile. :)


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.


I always encourage folks to read over the environment section of the manpage, as it's extremely helpful: https://docs.brew.sh/Manpage#environment


Sane defaults are important tough.


How to nuke it? Just in case...



[flagged]


Don’t do this! not only is it wrong for Apple Silicon Macs, you may be screwing up software not installed by Homebrew. Several GUI apps with CLI components install to /usr/local/bin.


Yes, I know, but most Unix things on my Mac are either installed by homebrew or myself, so I think it’s safe. But it’s a desperation act for sure.

Why do you say it’s wrong on Apple Silicon? If you mean system integrity protection stuff, I don’t think it applies to /usr/local


> Yes, I know

But other users might not, and you wrote that as a reply to someone asking how to do it. My comment was meant to warn others they should not go that route, especially when there’s an official uninstallation script (linked in my other comment).

> Why do you say it’s wrong on Apple Silicon?

Because in that case Homebrew installs to /opt/homebrew, not /usr/local.


Good call, thanks.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: