Live data from Hacker News

Homebrew 3.0

brew.sh

301–310 of 516 posts

Re: Homebrew 3.0

#301

One thing I haven't seen mentioned here is that Homebrew forced people use Ruby to write formulas (ie packages), whereas MacPorts forced people to use Tcl. This one decision, plus hosting formulas on Github, was a major contributor to their present success. As much as I sympathize (deeply) with all the criticism of Homebrew here on this thread -- I used to use MacPorts religiously and love it -- I don't think Homebre…

> I hate to say it, but if this was a race (?), Homebrew won. Thankfully we all still have the choice to use MacPorts if we want, but there's no point in being mean about Homebrew at this point either.

Definitely, plus there's also Nix and pkgsrc now, it's not like there's no alternative. And that's one race I lost trying to take the matter in my own hands with ArchMac[0] out of frustration with the limitations I faced with MacPorts and Fink, then Homebrew, so I pulled the plug[1] and trim the bills.

If anyone wants to take over just reach out.

[0]: https://www.archmac.org/

[1]: https://lna7n.org/2020/01/06/pulling-the-plug-on-archmac.htm...

Re: Homebrew 3.0

#302

Earlier quoted context omitted.

Yes. I'm really torn about brew. On the one hand, I hate to crap on the work that the maintainers have done, and it's clearly the best thing out there for macos. On the other hand, it's a terrible dictatorial piece of software that wants to command precisely how you use your computer; those same maintainers are actively hostile to users, as evidenced by the endless stream of nasty responses to issues, arbitrary chang…

You left out the entire generation of developers who are totally disconnected from how systems work and think that "it runs on my machine" should be good enough. Brew has lowered the bar enough that lots of folks simply don't have a clue how to deploy anything and worse, don't have a clue how to troubleshoot when something goes wrong in production. Obviously it's a double-edged sword. It's good to not waste time conf…

Not everyone wants to troubleshoot things in production. In fact I’d argue most people dont want to do that.

I’d certainly prefer to stay away from that type of hassle when I’m just trying to install a random package.

Re: Homebrew 3.0

#303
post #133

Earlier quoted context omitted.

+1. i like it but yes if i dont use it everyday and 2 weeks later go to brew install something, omg it has some gigantic update to do before i can brew install anything.

That is frustrating, but fortunately `HOMEBREW_NO_AUTO_UPDATE=1` will take care of it. Then you have to remember to update every now and then yourself, though.

Would you happen to know how to disable upgrading unrelated packages?

I often do `brew upgrade X`. Brew indeed does what is necessary to upgrade package X + deps. But then goes on and starts upgrading unrelated packages.

Re: Homebrew 3.0

#304

Earlier quoted context omitted.

My understanding is that the whole reason for running the outer commands as sudo is so that the inner build/install commands can be run in a far more restricted environment. Because brew runs as your own user, every build has access to your entire home directory, the whole homebrew folder, etc. It's nice in principle to not have to "trust" any of homebrew with sudo, but in reality, the trust surface area is far large…

I am confused by this. sudo seems like a far larger surface area than running as me. If it's just me then it's just me, but if it's sudo, then it's the entire box.

It depends whether you trust the tool maintainers more than the package definition maintainers. I certainly would. But don't take my word for it— here's a MacPorts developer explaining the sandboxing of builds:

https://apple.stackexchange.com/a/106942

Re: Homebrew 3.0

#305

One thing I haven't seen mentioned here is that Homebrew forced people use Ruby to write formulas (ie packages), whereas MacPorts forced people to use Tcl. This one decision, plus hosting formulas on Github, was a major contributor to their present success. As much as I sympathize (deeply) with all the criticism of Homebrew here on this thread -- I used to use MacPorts religiously and love it -- I don't think Homebre…

i honestly don't know the backstory on why you "hate to say it", and personally was a NeXT developer 25 years ago which I mention for context that I feel I missed out on something preferable in MacPorts, having found homebrew adequate.

Re: Homebrew 3.0

#306

Earlier quoted context omitted.

There is no criticism in their statement though, just a generalized opinion/rant that doesn't point out single issue and is factually inaccurate.

> doesn't point out single issue > is factually inaccurate. I think these two might be somewhat contradictory.

I don't, he said someone else would have filled the void, there was no void considering this project came after macports and fink

Re: Homebrew 3.0

#307
post #214
post #186

Earlier quoted context omitted.

Well I don't mean Linuxy in the architecture sense but Linuxy in the preparation and final stage installation sense. Like Homebrew does not need elevated privileges to work and actively discourages it. MacPorts, when something breaks, is a rabbit hole of elevated commands to bring it back to functional. Of course this is my opinion as I had Macports and Homebrew installed on my MBP 2012. I've swapped to a newer MBP a…

> Like Homebrew does not need elevated privileges to work and actively discourages it It does this by chowning /usr/local to a local user, which is worse for security than running sudo because now any malicious process can overwrite /usr/local/bin/bash without asking for privileges. macOS having /usr/local/bin in its $PATH by default also doesn't help. Homebrew made this security vs usability tradeoff because most Ma…

Running untrusted software on these sort of systems is fundamentally broken, no matter what the package manager chooses chown or not chown. A malicious program could edit ~/.bashrc to modify the user's PATH, or wrap sudo with a keylogger then use that password to chown anything it likes. That's not even a theoretical but unlikely sort of attack; it's quite trivial.

    > alias sudo='echo not what I expected'
    > sudo foo
    not what I expected

Re: Homebrew 3.0

#308
post #3

I can’t even begin to imagine how much value Max Howell (creator of Homebrew) has added to the world. It’s the recommended package manager at every place I’ve worked at and saves so much headache. I use Linux at home and package managers like AUR are great, but macOS is where the users are.

Contrarian view here: brew fucking sucks. It’s the worst package manager I’ve used for doing random unwanted updates at odd times. Someone else would have filled the void if homebrew hadn’t shown up, and it would hopefully have been better. I hate that brew is good enough that it’s got some kind of local maximum such that there’s no replacement forthcoming. There, I said it.

It’s hard to disprove this but IMO brew is the best package manager I’ve used (at least out of any of the widely used ones). I’m sure there is a better way to do things but given other common package managers that I find to be much worse, I’d argue it’s equally (if not more) likely that the alternative to homebrew would be worse.

Re: Homebrew 3.0

#309
post #239

Earlier quoted context omitted.

You're probably right about Homebrew feeling more comfortable for new users. Opinions on Homebrew may diverge with the answers to "How would you prefer to install? a) curl pipe to shell, or b) Download a DMG, double-click to install, and update your PATH." :)

a) curl pipe to shell b) Download a DMG, double-click to install These are not morally that different, the DMG installation can also do pretty much whatever, and I doubt people are picking apart the DMG to find the install script to verify that either.

I'm definitely not resuscitating that old argument here.

Just noting that people have strong opinions about the preferability of either approach.

Re: Homebrew 3.0

#310
post #21

Been a MacPorts user for years and I know nothing about Homebrew. To those who tried both: should a software engineer switch to Homebrew? MacPorts has its own way of dealing with dev tools and framework versioning. E.g. you can have multiple versions of complex products like PHP or MySQL at once. You can even have a GCC package for a specific target arch as a separate ports package. Does Homebrew allow these things?

Have never used MacPorts, but based on your comment, and a few of the replies, I may give it a try. Homebrew is quite painful in many ways, particularly when managing multiple versions of a package (MySQL & PostgreSQL especially has had a lot of issues for me). On the other hand, what I will say in favour of Homebrew is that its popularity does make life much easier as there's so much software available on it. Even v…

You would probably enjoy the `port select` command in Macports to pick the version you want to launch when invoking, say, "python".

Macports is also good about naming different versions, so you can have python-34, python-37, and python-29 installed together.

Post reply on HN