Live data from Hacker News

Homebrew 3.0

brew.sh

211–220 of 516 posts

Re: Homebrew 3.0

#211
post #162

Earlier quoted context omitted.

Homebrew was nice up until they packed it with spyware and then subsequently forced full tree clones† down the users' throats. It still might be useful for some people, but it certainly fell by the wayside. What a shame… †) As a result, Homebrew grew literally hundreds times larger and became unbearably sluggish. . PS: I'm wondering what drives some people to downvote this very comment… Stockholm syndrome maybe? ;P

People are probably downvoting it because in a scant few lines you manage to pack in two lies and a half-truth. It is not packed with spyware, it has not fallen by the wayside, and the full clone is due to a request from github to reduce the load caused by homebrew users (as in it is so popular that it caused a noticeable impact on github servers.)

Stop calling names and searching for lies where there are none. I didn't bother explaining that all, because I assumed people coming here are already Homebrew users, as those who are usually already know that all. It's just pity to see where is it going[0][1]…

--

[0] Regarding spyware: https://github.com/Homebrew/brew/blob/master/Library/Homebre...

[1] Regarding the forceful approach to unshallowing, they just chose the easiest way they could. You'd literally had to meddle with the code in order to accept shallow clones again. They didn't even bother to make a switch for advanced users.

Re: Homebrew 3.0

#212
To take a (lol) contrarian view compared to the rest of this thread, I think brew is great with the exception of the upgrade/update nonsense, which makes me utterly furious every time I try to update (or is it upgrade?) one of my brew-installed tools.

Re: Homebrew 3.0

#213

Earlier quoted context omitted.

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.

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…

I already stopped using Mac, but for people still using Mac: you really should give nixpkgs a try.

Re: Homebrew 3.0

#214
post #186

Earlier quoted context omitted.

I always thought that brew was the "Linuxy" one and Macports was FreeBSD Ports for the Mac.

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 Mac users are a single user, which makes sense in its context.

The recent change of moving Homebrew to /opt/homebrew (at least for M1 Mac) is a better solution for this as it is no longer in the default $PATH. On the other hand, MacPorts approach of requiring sudo allows it to drop privileges to other unprivileged non-admin user (macports) during build in addition to building everything via sandbox-exec.

Re: Homebrew 3.0

#215
I personally found Homebrew to be really helpful when I looked at MacOS as a unix environment and tried to engage in local development as if it were a unix environment.

[Un]fortunately, I've stopped looking at MacOS in this way. I now look at MacOS as the better version of ChromeOS that runs on non-shit hardware (two time PixelBook owner, both of them had serious hardware issues, and getting support from Google for what they view as throwaway devices is not at the same level as the Apple Store/Genius Bar experience).

Taking the view that MacOS is a fat client for apps and browser use, that is capable of also running [Uni|linu]x VMs, and pushing myself to adopt the "local editor, remote runtime" working model, has been really liberating.

I now no longer look at Homebrew as necessary. Instead, I can use package managers built for operating systems that are intended to work with package managers and that whole ecosystem, rather than fighting against Apple's efforts to improve the local security environment.

In many ways, I feel like I've come full circle to where I was at in the mid-00's, working in a SaaS/enterprise environment developing on Windows using VMs for actual dev work so as to keep my local machine safe, healthy, and productive.

Rather than dealing with the annoyance of Docker for Mac, I can instead just work in a VM running normal docker, or one of the competing solutions, and this translates very closely to what I run if I'm working against a VM.

And if you are doing anything "serverless" or "server-light", it's even less helpful to try and continue working with the MacOS terminal userland.

So, hats off to homebrew for all they do, but I really think the puck is moving elsewhere and that's where I'm headed instead.

Re: Homebrew 3.0

#216
post #191

Earlier quoted context omitted.

Fwiw you can use the Nix package manager ( https://nixos.org/ ) on OS X to accomplish those same things. Lots of discussion about that the past few years: https://google.com/?q=nix+on+mac+os+x Nix has more packages than MacPorts - 60k vs 37.6k - though that's not necessarily a guarantee the ones you need are there. And like MacPorts it doesn't do weird, non-Unix-y ownership changes of system directories like Homebrew…

Unfortunately, Nixpkg doesn't check buildability on Darwin when merging PRs, so things can break quite often on the nixpkgs-unstable channel (compared to nixpkgs-unstable on Linux). It's not hard to rollback, though, but it does makes me never want to ever run `nix-channel --update`.

Use one of the Darwin channels, that won't advance unless Darwin things are not too broken.

Re: Homebrew 3.0

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

so, you don't do a 'yum update' before installing software on your system (or 'apt-get update' or whatever)? Are you also the type of person that refuses to update system software because "it takes too long, and I'm too busy"?

Not GP, but I do it quite often, but not every single time. Also yum/apt/etc updates are way faster and much more responsive than brew.

Re: Homebrew 3.0

#218

Earlier quoted context omitted.

> found it a bit cumbersome with the “no sudo” requirement This is one of the few features I do love about Homebrew. Does MacPorts have a "no sudo" mode or does it just let all packages run rampant on your system?

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…

> every build has access to your entire home directory, the whole homebrew folder, etc.

Isn't this just whataboutism though? Yes that's potentially a problem but it's an orthogonal one. So not really relevant to this discussion.

A hypothetical solution to the problem in the linked XKCD would be to somehow prevent an attacker accessing your bank, it would not be to allow an attacker to install drivers without your permission.

> With MacPorts, you only have to trust the tooling, not the individual package definitions (though obviously the calculus does change slightly when bottles are in the picture, since then the build/install is happening elsewhere).

This calculus change is basically my primary concern.

Of course it's not ideal that Homebrew apps have access to everything in my Home, but that's still better than them having access to everything on my system.

Re: Homebrew 3.0

#219
post #187
post #128

Earlier quoted context omitted.

MacPorts and Homebrew have a different philosophy of software installation. MacPorts wants to have its own thing over in /opt where it has its own toolchain independent from the system tool chain. This means that all users on the system share the same MacPorts software. This has an additional impact that it means that it requires privilege to install software there. Homebrew, on the other hand, uses the system toolch…

> This means that all users on the system share the same MacPorts software. This has an additional impact that it means that it requires privilege to install software there. > Homebrew, on the other hand, uses the system toolchain and tries to avoid using root. What? Homebrew wants you to change ownership of /usr/local to your individual user and refuses to run without doing so. How is that any different as far "as a…

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?

Re: Homebrew 3.0

#220

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 don't recall how I came across it but remember well the relief after using it the first time. It was the first package manager on MacOS that worked and made installing common tools painless. With MacPorts, fink etc it felt like it would have been better to built from source yourself.
Post reply on HN