Live data from Hacker News

Homebrew 3.0

brew.sh

291–300 of 516 posts

Re: Homebrew 3.0

#291
post #234

Earlier quoted context omitted.

Huh? I'm on Big Sur running homebrew. 'ls -l /usr' reveals that /usr/local is root:wheel just like all other folders under /usr. How exactly is homebrew changing ownership?

Any chance you're on Apple Silicon? For some reason homebrew uses /usr/local on Intel macs and /opt/homebrew on ARM macs. Anyway, this requirement is well documented and not new: https://github.com/Homebrew/brew/issues?q=is%3Aissue+%2Fusr%... http://github.com/Homebrew/brew/blob/master/docs/Installatio... Homebrew asks users (on Intel macs) to change the ownership of /usr/local to their local user. And it refuses to…

> Homebrew asks users (on Intel macs) to change the ownership of /usr/local to their local user.

Nope - intel Mac on Big Sur:

drogers@SJCMACJDYMD6M ~ % ls -l /usr

[snip]

drwxr-xr-x 15 root wheel 480 Dec 14 20:10 local

[end snip]

And for the record, neither of your links support your claim.

Re: Homebrew 3.0

#292

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…

Those were one of the reasons, but I believe the biggest reason was MacPorts didn't install from binary archive and requires building everything from source in its early days (in the old BSD port tradition). Binary archives were added to MacPorts in 2011 with MacPorts 2.0, but a lot of people (me included) has already moved to Homebrew, leaving MacPorts with an impression of old, slow, and make your Mac fry an egg.

MacPorts these days behaves similar to Homebrew by installing from binary archives by default and only build from source when binary archive is not available. This vastly improved the experience, but the old impression remains for those who got burned (literally for some) by MacPorts. 10 years is a long time, and MacPorts has improved a lot since then.

Re: Homebrew 3.0

#293

Earlier quoted context omitted.

The usual non-productive rant. What prevents you to do it better then? What prevent you from forking it? Sharing improvement ideas? Contributing to the project? "It sucks" doesn't help anyone understand your frustrations and does not serve the message you're trying to share (let this one be valid or not). Also, as everything that is open-source/free: if you hate it, don't use it, that's it. And let the people who app…

Not parent, and I'm not going to say it sucks, the project takes a lot of work from a lot of people and I ain't the one pissing on other people's work, it definitely could use some improvements syntax wise though, What was it, brew install? Brew cask? Oh , now is brew cask install... or was it brew install --cask? I get the analogy, but being a package manager, but was it really that bad to use 'brew install', 'brew…

> I get the analogy, but being a package manager, but was it really that bad to use 'brew install', 'brew update', and 'brew upgrade' for everything?

That’s how it works now. You only need `--cask` for (rare) disambiguations.

Homebrew Cask started as a different project (casks and formulae are still inherently different), so not having `brew cask` only became viable after the two projects merged.

> it is a little frustrating at times when you don't use it for a while, you 'brew install xx' and wait 4 minutes until "Updating homebrew" finished

Use `HOMEBREW_NO_AUTO_UPDATE=1`. Just don’t open an issue if something breaks and you didn’t update beforehand.

> which I assume is refetching repos, but couldn't know it from the output

`--verbose`.

Re: Homebrew 3.0

#294

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…

Well, to be clear, developers who say "it runs on my machine" aren't a "new generation of developers" so much as "bad software developers".

There's no world where that excuse is okay. It's also not all that related to Homebrew, though...

Re: Homebrew 3.0

#295
post #270
post #195

Earlier quoted context omitted.

> it's a terrible dictatorial piece of software that wants to command precisely how you use your computer I've also seen examples of where Homebrew is basically dictating on how to release your software as well. There was that one case where they decided to delete the formula for mpv since mpv didn't have a recent enough of a tagged release. https://github.com/danielbair/homebrew-core/commit/b18f104f1... There was al…

That one doesn't seem unreasonable. They have a "we only support tagged releases" policy. mpv moved away from tagging releases for a bit, and their latest tagged release couldn't build on current MacOS. So they switched it to the part of their system (casks) that supports downloading and installing arbitrary binaries instead. I think it's a fair conflict, too. For a package manager, saying "just download and compile…

I suppose their hand was probably forced by Apple in some way, but simply offering binary downloads for mpv in particular is subpar. There are a lot of unusual options for mpv that, in my experience, don't get pulled into prebuilt binaries. For instance, last I checked, the prebuilt packages for mpv from homebrew didn't have librubberband support. LibRubberband is great, but to effectively integrate it into your workflow you need some userscripts that mpv doesn't ship with, so many users (including packagers evidently) may not see the value in it. When I was still using MacOS, I had to build mpv myself to enable it. My memory is hazy, but I think libarchive support was in a similar situation. Eventually I cut homebrew out of the picture and chose to build mpv myself, since homebrew wasn't helping at all, just getting in the way.

Re: Homebrew 3.0

#296
post #250

Earlier quoted context omitted.

MacPorts seem to be very “user” friendly for people with Unix and/or Gentoo (maybe a bit Arch too) background. I have experience with all three and when I needed to decide in between HomeBrew and MacPorts, it was very simple choice. I tried both to get the actual experience and stuck with MacPorts. All the naming in HomeBrew was just too confusing too me.

Gentoo is probably the most user hostile Linux distribution I can think of other than ones purposely austere for learning (LFS) or parody (Suicide Linux). If Mac Ports requires that level of knowledge to be user friendly it’s no surprise they lost.

If Gentoo makes your particular computer goal easier to achieve, I don't think it's "hostile".

Most people will never need Gentoo or want to use it, but for those with either a need or a desire for a meta-distribution, Gentoo does a pretty good job. I don't think calling it "user hostile" is quite right.

I think it's been partially supplanted by other package managers now like Nix/NixOS and even (IMO) XBPS/Void, but Portage does an alright job.

Re: Homebrew 3.0

#297
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.

> I hate that brew is good enough that it’s got some kind of local maximum such that there’s no replacement forthcoming.

You may be interested in trying out nix for package management [1], or even for configurations and providing development environments (see my other comment [2]).

[1]: https://builtwithnix.org/

[2]: https://news.ycombinator.com/item?id=26038614

Re: Homebrew 3.0

#298
Not really on-topic but am I the only one? I stopped developing locally, my notebook is just a thin client ssh'ing into a remote dev server. I get all amenities like developing on the production os, no awkward package managers, 1 GBit up and down—always and anywhere and Docker pushes within few seconds.

Re: Homebrew 3.0

#299

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…

This makes no sense. First, nobody deploys anything to macos in production. Second, dragging an icon the applications folder (pre-brew method) does not "connect you to how the system works".

Re: Homebrew 3.0

#300
I am fascinated by the polarizing nature of Homebrew on HN. I've used both MacPorts and Homebrew, and I think the only reason I switched to Homebrew years ago was that Homebrew didn't try to install stuff at a system level, which felt more in line with a package manager that wasn't integrated into the OS.

But I'm sure MacPorts is fine still. Why are people so strongly opinionated about this, particularly on the pro-MacPorts side? Nothing I've seen in the comments so far jumps out as an obvious source of the passion.

Post reply on HN