Live data from Hacker News

Homebrew 3.0

brew.sh

411–420 of 516 posts

Re: Homebrew 3.0

#411

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.

Homebrew maintainer here: I'm sorry that we don't meet your expectations. Two things for your consideration: 1. It's uniquely visible among system package managers. When people have problems with a package in `apt` or `dnf`, they find a community or third-party repository for the package or bug the upstream directly. By contrast, Homebrew has always been visible on GitHub, does not require a special login to a bugtra…

> We operate at Apple's whim, which generally ranges between neutral disinterest and actively trying to remove parts of the macOS userspace that we rely on.

I know you're not unique in this assessment or consequence, and that's truly a shame.

Re: Homebrew 3.0

#412
post #376
post #315

Earlier quoted context omitted.

Why is it bad that homebrew puts files in /usr/local? Edit: They use /opt if you're on Apple Silicon https://github.com/Homebrew/brew/blob/master/docs/Installati...

There's nothing wrong with installing packages into /usr/local, but brew turns /usr/local into a git repository and IMO that is wrong. Also, brew acts like it's made for a single user, as it changes files and directories to be owned by the user running it, but /usr/local is a system directory. When I install brew, I always put it into my home directory instead of /usr/local.

It turns /usr/local/Homebrew into a git repository; not /usr/local itself. Whatever it links into /usr/local/{bin,include,lib,sbin,share} is just a symlink into /usr/local/Cellar.

Re: Homebrew 3.0

#413
post #378

Not to be the eternally dissatisfied user, but I've never gotten homebrew to work properly on a machine with multiple users. It only works for 1 user at a time, even if it's owned by a user group that both users belong to. Has anyone else had that problem or found a solution?

Homebrew maintainer here. I do suffer from the multi-user problem myself, and happily work around it on my own Mac by maintaining a dedicated `brew` user, to which the actual users have passwordless sudo rights.

I’ve taken notes of my workaround, if it helps: https://gist.github.com/claui/ada85e696029cfa8cba9b91723ce2e...

Re: Homebrew 3.0

#414

Earlier quoted context omitted.

To codify both replies to yours as an outsider who watches macOS coworkers struggle: brew is akin to running Arch, where the concept is latest-tagged-release of any given software. The newest version of X introduces a feature which has a need of Y library (dependency) >= n+1, where n is your already installed version. It just so happens that Y is shared between 3 applications; so if you upgrade Y to satisfy X, you no…

> Brew is more "AUR-like" where it's all down downstream on your own system, so you get to deal with the work and churn through the recompiles yourself. I don’t see how Homebrew would be similar to AUR. Unlike AUR contributors, Homebrew maintainers curate the packages, test them, monitor upstream projects for updates, build and upload binary packages and do their best to support users when anything breaks. Anytime a…

It depends on the formula, designs and maintainers of them - we run an internal tap and some items are casks, some are bottles and some are compile as you go. It just depends on what that widget is and does, and in some cases there are tools which are broken on latest-tagged releases and people have to pin older versions or using git HEAD for (some period of time) until the tagged released is fixed upstream. (we're looking at you, sshuttle-who-deprecated-remote-python2-in-v1.0-thru-1.0.4-and-broke-lots-of-workflows-with-jumphosts)

Re: Homebrew 3.0

#415
post #378

Not to be the eternally dissatisfied user, but I've never gotten homebrew to work properly on a machine with multiple users. It only works for 1 user at a time, even if it's owned by a user group that both users belong to. Has anyone else had that problem or found a solution?

Homebrew maintainer here. I do suffer from the multi-user problem myself, and happily work around it on my own Mac by maintaining a dedicated `brew` user, to which the actual users have passwordless sudo rights. I’ve taken notes of my workaround, if it helps: https://gist.github.com/claui/ada85e696029cfa8cba9b91723ce2e...

Interesting! Thank you!

Re: Homebrew 3.0

#416
post #319
post #63

If you wish to donate, then you can do the creator a favor: https://mxcl.dev/#donate

Without taking away from Max Howell, he hasn’t been with Homebrew for years. Anyone is still free to donate to him (naturally), but those will have no impact on Homebrew. To donate to Homebrew, see https://github.com/Homebrew/brew#donations

Great point, thanks!

Re: Homebrew 3.0

#417

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…

It reminds me about this answer from Homebrew's creator, Max Howell, on Quora[1]:

> I wrote a simple package manager. Anyone could write one. And in fact mine is pretty bad. It doesn't do dependency management properly. It doesn’t handle edge case behavior well. It isn’t well tested. It’s shit frankly. > Is it any surprise I couldn’t answer their heavily computer-science questions well? > On the other hand, my software was insanely successful. Why is that? Well the answer is not in the realm of computer science. I have always had a user-experience focus to my software. Homebrew cares about the user.

Yes, Homebrew's approach on package management is a bad smell to me. It gets broken by every other major OS update, it messes up your Python PATH for no good reason, it forces a lot of opinionated decisions on users if the maintainers think it benefits the majority(and ignores voice from minority)... But Homwbrew still wins because users really like it. It is that simple. With its popularity and the strong community, it will continue to be the top choice for most of the mac users. Max Howell may not be a rock star programmer in my mind, but I have no doubt that he could've been a very successful product manager.

Personally I don't plan to switch from macports to homebrew any time soon, but I stopped grumbling about how bad it is years ago.

1. https://www.quora.com/Whats-the-logic-behind-Google-rejectin...

Re: Homebrew 3.0

#418
post #226

Earlier quoted context omitted.

Do you mean apt or apt-get or apt-get install or was it apt-install --get?

even on old infrastructure its already apt and nothing else anymore. So they advanced.

No, it's really not. apt-get works just fine on my current Ubuntu instances.

Re: Homebrew 3.0

#419

Earlier quoted context omitted.

I don't buy the premise that package managers are the reason why companies need DevOps. Software deployment has gotten complicated for a variety of reasons (containerization, micro-services, continuous integration, cargo-culting FAANG practices, etc). When I first started my career, I FTP'd my code changes into the single production server that ran both Apache and MySQL. Homebrew is not the reason I don't do that any…

That's not really the argument that I'm making. I am a deployment engineer. Deployment is actually really easy. I'd argue that it's not far off from FTPing your code changes over in terms of difficulty. No, my argument is that more engineers today do not know how computers work. I'd even argue that many engineers would find FTPing over code changes to be too difficult (or they'd screw it up). My argument is that home…

While I sympathize, I think that train left long time ago.

I had that aha moment, when during early 2000s I found myself explaining to C++ developer what linker is and what exactly it does. Until then, it was just the thing that VC++ did as the last step after clicking the Build menu item.

It certainly didn't improve since then.

Re: Homebrew 3.0

#420
post #312
post #259

I'm definitely grateful that MacOS has a package manager at all. Mac before the unix-like OS X days was like using Windows: you had to hunt for installers or DMG's. Except Mac didn't have the legacy support that Windows aims for: all your programs would break when a major update like MacOS 8 came out.

The bigger pain point for me is macOS still has no system-wide registry of installed applications. You specifically need to keep the uninstaller around for big applications. So lord help you if the app you want to delete isn't a single .app file in /Applications

Homebrew helps you with that, even if the app was installed without Homebrew:

brew uninstall --zap --force CASKNAME

Post reply on HN