Hacker News Reader

Comment by paultopia | Hacker News Reader

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 changes to disable any functionality that they believe anyone has ever misused by their standards ever, etc. I pray daily that someone will fork it.

View on HN

The decisions to enable auto update, the removal of `--with-foo` options, breaking the `brew list` command and the removal of `depends_on :x11` were all mistakes, as I see it. I have read loads of issues and pull requests to understand the reasoning but have yet to find arguments that I think justifies those breaking changes.

I get it, it's all made by volunteers, but I wish there was a package manager for macOS that was focused on professional users.

I wonder if the decision process in Homebrew has relied perhaps too much on analytics data leading to the dismissal/ignorance of features used primarily by users who have disabled analytics via the HOMEBREW_NO_ANALYTICS environment flag.

>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 also an instance with mpv where Homebrew devs got pissy about mpv not supporting Lua 5.3 and mpv devs got angry at Homebrew devs for asking to break existing user scripts to appease one package manager.

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 master wherever it is right now" is rough, and I can understand them not wanting to have to look at mpv's repo and pick a good commit to pin as their "release". Offloading picking a stable release point to someone else is legitimate.

To add to what you said, the formula came back a week and a half later when they returned to tagging releases.

https://github.com/Homebrew/homebrew-core/commit/82a45025682...

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.

> dictatorial piece of software

Isn't that generally the point, for Apple consumers? At HN we have a skewed sample but I imagine for a lot of users (myself included), having an easy solution with configurations set for you is exactly what they want.

That's what I want.

I build web apps for a living, and I used to do it by contracting. I don't have time, patience or interest for fiddly configuration. I want a mostly-good initial experience so I can get on with my work rather than mess about with my tools. I'm aware there's some gain to be had by knowing more about my tools, but the payoff isn't obvious enough to make me change my ways.

Thanks for being mostly-great, brew.

Exactly, it’s the same reason I use Mac instead of Linux. I want to make things. I don’t want to waste time fiddling with endless verbose details I don’t need to know

Yours, A Noob

Not for developers, no. "Normal" Apple consumers have little reason to use brew.

I think that's a false dichotomy. I think there are plenty of "normal" Apple consumers who may not be an HN-level hacker but would still be considered "developers".

What is a "HN-level hacker"? I write code for a living and I read news on this website. Do I count?

I'm an apple "consumer" because I don't want to think about any hardware gotchas when I'm trying to do my job. That's the same thing I want out of my package manager, sensible defaults I don't have to think about so I can do real work instead.

Homebrew has clear value even if you aren't a developer. It's the best way to install a whole lot of software, not just dev tools.

I'm not a developer and I have plenty of reasons to use homebrew.

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

+1. I’ve been using it for a while, and it fixes my problems with homebrew - mostly that homebrew breaks features every couple of weeks in small point releases, which you get automatically upgraded to

Auto upgrade sucks but it is possible to turn it off

But then what? You still have to deal with the mess when you do manual upgrades.

Nix seems to be the Crossfit of the computing world.

How do you know someone uses Nix? They'll tell you :D

How does it "command you how to use your computer?" A brew formula is a simple ruby script that lists the packages dependencies, and calls "make; make install". Typically it allows you to set any autoconfig vars and remembers them for next time. This is literally just a thin layer of abstraction over grabbing the tarball and installing the software yourself.

Also brew does not stop you from installing a piece of software literally any other way you prefer if for some reason you don't like what the brew formula is doing, including just creating your own tap.

I find Nix to work better on macOS than Homebrew, and it doesn't embed spyware in the package manager like Homebrew does.

Ah, this reminds me of how shitty the maintainers were to me when I said I was using hackintosh (for an issue that had nothing to do with it).

Apologies about that. I’m sure none of us wants to be shitty to anyone. It’s never ok when we are.

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 configuring your workstation, but ultimately I'd argue in brew's case too good to be true.

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".

I don't understand this critique. Is this a complaint about package managers in general, or is `brew install git` lowering the bar from `apt install git`?

It's about a trend of developers who don't know how to interact with their system beyond `brew X Y` and the disconnect between the software on their Mac and the software on a production system.

There's a huge disconnect between A & B so much so that it's created an entire role for people like me that otherwise shouldn't exist.

I've been in the industry long enough to see a decline in ability for lots of developers beyond kicking deployment over the wall for someone else to figure out (not that this didn't exist before).

Notice how many companies have dedicated DevOps roles in their ranks whereas everyone and their mother who is a practitioner has been saying since the very beginning that that's now how it should be.

Your complaints seem to boil down to "get off my lawn" and it's rather tedious. what do you get out of it other than a feeling of superiority?

It's not at all. It's a reaction to the learned helplessness from colleagues I've had to work with. It's exhausting to be relied upon for everything, especially when the compensation isn't matched appropriately (although most management I've encountered have appropriately engineers who do disproportionate heavy lifting). Our industry needs to do better.

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 anymore.

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 homebrew makes some amount of contribution (not 100% the reason for) engineers remaining ignorant about computers.

Homebrew was the first package manager where I actually looked under the covers because everything was pretty easy to follow. I regularly use 'brew edit <formula>' just to see how something is built. I don't see how brew obscures the internals of my computer at all.

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.

Do you know how to directly 'talk' to the CPU or GPU? Do you build everything from source? Are you comfortable writing assembly? Have you recently soldered shit or built a PC from scratch?

Yes, when it makes sense to, yes and yes.

I'd be happy to work with people who know system calls & exit codes though. And basic network protocols. And how to read an RFC.

> Notice how many companies have dedicated DevOps roles in their ranks whereas everyone and their mother who is a practitioner has been saying since the very beginning that that's now how it should be.

I dunno who says that but they're dead wrong. I'm working as a dev somewhere with a dedicated DevOps finally after years of being dev + ops (+dba +sysadmim +qa) and I can't tell you how much of a relief it is to have other people shoulder that stuff so I don't have to think about it.

I understand your point that devs who have a higher level understanding of systems and deploy pipelines and such are probably able to write good systems themselves, but when it comes to the humans doing the work? I absolutely love having it separated.

It feels nice but organizations with cross-functional teams are outmaneuvering yours and probably by at least 3x.

I'd rather work harder at a business that succeeds and has equity that's worth a damn.

That's fine, I'd rather work on stuff I enjoy and have a life outside of work.

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

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.

Nobody's saying you should want to.

This is a conversation about ability level.

Reply on news.ycombinator.com