13 ms·

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 fille

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.

gagarine 6y ago
I rage quit Homebrew to MacPorts. No complain after 2 years. Not a single bug. Installation are much faster than 10 years ago too (macports use pre-compiled binaries now). Give it a try if you have some time to lose.
smoldesu 6y ago
I agree with you wholeheartedly. Homebrew was my least favorite part of the MacOS experience, which is a shame since it was basically the most important piece of software I had installed on that thing.
my123 6y ago
MacPorts meanwhile existed years before Homebrew, and is alive and well.
yardie 6y ago
Macports? They’ve been around even longer than brew. But they were always a bit too Linuxy for most Mac users.
- flemhans 6y ago
  I always thought that brew was the "Linuxy" one and Macports was FreeBSD Ports for the Mac.
  - sirn 6y ago
    Jordan Hubbard was involved in the creation of both FreeBSD Ports and MacPorts (DarwinPort), so it makes sense that it shares the BSD ways of doing things. His decision to use Tcl for MacPorts also came from his experience dealing with Makefiles[1] [1]: https://netbsd.org/gallery/10years.html#hubbard https://netbsd.org/gallery/10years.html#hubbard
  - yardie 6y ago
    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 and I only have HB installed. Since most packages are on HB I no longer need to have both installed.
    - sirn 6y ago
      > 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.
      - LiberatedLlama 6y ago
        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
        sirn 6y ago
        That's fair, but it's only affecting single user, while writable /usr/local affects all users. However most Mac users are single user, so the tradeoff makes sense in this context.
- eecc 6y ago
  Linux? Macports take direct inspiration from FreeBSD ports
deleted 6y ago
[deleted]
qntty 6y ago
What do you mean by random unwanted updates? As far as I know, the only way to update is by running brew upgrade.
- regulation_d 6y ago
  one time i ran “brew upgrade ffmpeg” which somehow forced a major version bump of postgres.
  - deleted 6y ago
    [deleted]
  - juandazapata 6y ago
    I installed awscli and somehow emacs ended up installed in my system.
- w0m 6y ago
  Personally; only issue i tend to have is that when I install X, it breaks Y forcing reinstallation of ~everything. What should be a small install ends up taking 30m of cleanup. Entirely likely it's user error on my part; but also problem I haven't really had with other 'nix package managers.
  - deleted 6y ago
    [deleted]
  - Doctor_Fegg 6y ago
    Which isn't funny when Y is Postgres and your database is no longer readable post-upgrade. Happened to me.
- stonesweep 6y ago
  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 now have to recompile/upgrade (depending on details) A, B and C as well to use the newly updated version of Y. Arch (and other rolling releases) do/does this every day, it's just that the work is offloaded to upstream packagers. 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.
martpie 6y ago
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 appreciate it be productive and build awesome tools with it.
- w0m 6y ago
  > What prevents you to do it better then? What prevent you from forking it? Sharing improvement ideas? Contributing to the project? I think ~everything he stated is generally assumed true. I use Brew installed software every single day, and appreciate it. That doesn't put it above criticism though.
  - bastardoperator 6y ago
    There is no criticism in their statement though, just a generalized opinion/rant that doesn't point out single issue and is factually inaccurate.
    - zimpenfish 6y ago
      > doesn't point out single issue > is factually inaccurate. I think these two might be somewhat contradictory.
      - bastardoperator 6y ago
        I don't, he said someone else would have filled the void, there was no void considering this project came after macports and fink
  - bakedbeanz 6y ago
    "brew fucking sucks" is just whining, not reasonable criticism IMHO
- 6y ago
Gelob 6y ago
+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.
- dylan604 6y ago
  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"?
  - wpm 6y ago
    No, I don’t like forced 5 minute stops to my work. Yes, I’m the type of person who only updates on my schedule when notified, or when I need something. These little tools installed by home brew aren’t just little tools, they’re dependencies for whatever else they’re used in. The fact that I need package “X” doesn’t mean I want package Y, something entirely unrelated, updated without my consent. It’s MY fucking computer. Let ME decide what software gets installed on it and when.
  - ratww 6y ago
    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.
  - eknkc 6y ago
    I generally don't do an apt update before installing a package that I needed at that moment. However I do full update / upgrades when it is convenient for me. That's the point.
  - Schalter 6y ago
    I have the same issue and for me there is a simple difference: I probably use homebrew for a handfull of tools, in debian etc. my packagetmanager manages everything. Its not a huge issue but the thought of 'ah shit i need to run update' comes with 'that will be slow'
- 6y ago
kspacewalk2 6y ago
"Someone else would have filled the void if homebrew hadn’t shown up, and it would hopefully have been better." MacPorts and fink existed before homebrew took over, and they weren't better. That's why homebrew took over.
- quesera 6y ago
  But Homebrew wasn't (and isn't) better than MacPorts, either. They both work well (we can and do quibble about the internal mechanics of each), and appeal to different groups of people. My theory is that Homebrew was announced at exactly the right time in the MacOS adoption curve. A huge number of new users arrived with no existing knowledge of MacPorts or Fink. Most of them didn't know they needed a package manager at first, but when the momentum picked up, Homebrew was the new option with a better web page, a more collaborative working model, and hosted at GitHub (also ascendant). I'd also argue that similar factors were involved in Linux's popularity over BSD in the 1990s. Timing, environment, adequacy, and luck. All are required. Superiority is not.
  - volta83 6y ago
    I used MacPorts before hombrew. Homebrew "just worked", MacPorts sucked. Maybe I was too dumb to use MacPorts, but all other MacPort used I knew back then all moved to homebrew very quickly.
    - thaeli 6y ago
      This, so much this. I tried to use MacPorts. It was pulling teeth every time. Brew was a It Just Works breath of fresh air. I agree that it's a very opinionated tool, and note that those opinions fit in well with the Mac ecosystem. They aren't as good a fit for Linux or Windows.
      - novok 6y ago
        I think often 'it just works' and 'opinionated' goes hand in hand. Without choosing what to say no to, you create infinite workload with finite amounts of people and thus something breaks, somewhere.
throw0101a 6y ago
Besides the already-mentioned MacPorts, NetBSD's pkgsrc is multi-platform, including macOS (AFAICT): * https://www.pkgsrc.org/ https://www.pkgsrc.org/
- smazga 6y ago
  Yeah, it works on macOS and is actually very nice, but its package catalog is not quite as comprehensive and OS upgrades are a huge headache. In other words, a solid alternative with a different set of issues.
- jperkin 6y ago
  macOS users may want to use my binary package repository, updated every few days from pkgsrc trunk: https://pkgsrc.joyent.com/install-on-osx/ https://pkgsrc.joyent.com/install-on-osx/
game_the0ry 6y ago
I am cool with constructive criticism, but you do realize brew is free, right? If you are not happy with open source, you have a couple of options: - build your own brew - brew is open source, so you can make contributions to improve - pay for something like brew (though probably not an option for brew) Have you done any of the above before complaining? I am guessing - no. Otherwise, say "thank you" and move on, my friend.
- Enginerrrd 6y ago
  I get where you're coming from, but I think the open source community benefits from being, well, open. Walling yourself off from user frustrations and criticism with the attitude that they are ungrateful is not how projects evolve to better meet user needs.
- oreille 6y ago
  You sure sound absolutely cool with criticism.
- dmitriid 6y ago
  Being free doesn't absolve it of criticism.
loriverkutya 6y ago
When I get angry about brew sucks I always remind myself there is npm.
- cmehdy 6y ago
  When I get angry about npm, I remind myself there is gradle.
  - Gaelan 6y ago
    When I get angry about gradle, I remind myself there is autotools.
    - deleted 6y ago
      [deleted]
paultopia 6y ago
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.
- Hamuko 6y ago
  >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/b18f104f14350b58b9d6d5b8280af073327bf0b8 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.
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - kemayo 6y ago
    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.
deleted 6y ago
[deleted]
volta83 6y ago
> There, I said it. What a waste of bytes and bandwidth. "[homebrew] It’s the worst package manager I’ve used" is true for all users that have only used one package manager. The opposite claim ("it's the best I've used") would simultaneously be true. You could at least have mentioned _why_ and that could have kickstarted a meaningful discussion, but instead your comment is the equivalent on a thumbs down in a youtube video.
- anaerobicover 6y ago
  Pot, meet kettle: https://news.ycombinator.com/item?id=26037357 https://news.ycombinator.com/item?id=26037357 > volta83 1 hour ago | parent [–] | on: Homebrew 3.0 > I used MacPorts before hombrew. Homebrew "just worked", MacPorts sucked. > Maybe I was too dumb to use MacPorts, but all other MacPort used I knew back then all moved to homebrew very quickly. > reply
tomlin 6y ago
If you've used Valet, you know truly that Brew is the worst.
deleted 6y ago
[deleted]
prpl 6y ago
It might not cover everything, but it also has a superset of other things more - conda + conda-forge (with mamba too for better performance) The had also apple silicon support for many things more than a month ago.
onedognight 6y ago
export HOMEBREW_NO_AUTO_UPDATE=1
- filleduchaos 6y ago
  That doesn't solve the evergreen packages problem, and I'm tired of people trotting out this flag when people (rightfully in my opinion) complain about brew upgrading literally everything it can get its hands on.
woodruffw 6y ago
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 bugtracker on some random domain, and thus receives direct community support volume that we need to address. 2. Homebrew is not an official system package manager. 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. Many of our changes over the last decade (installing our own Ruby, rolling back custom source options) can be directly traced back to changes that Apple imposes that produce disproportionately greater maintenance effort from us.
- jedbrown 6y ago
  Point 2 here is huge. If Apple cared about open source or cross-platform developers, they would pay at least one full-time Homebrew developer and upgrades would be smooth. It speaks volumes that they are swimming in money and can't be bothered to make a token gesture.
  - woodruffw 6y ago
    > It speaks volumes that they are swimming in money and can't be bothered to make a token gesture. I agree with a lot of the sentiment here, but I want to make one important correction: Apple has helped us. In particular, they gave us access to DTKs for the M1 and provided us with a liaison for the migration. We're very thankful for that help. That being said, Apple is a massive company and they have their own development goals and velocity for macOS. They're not actively looking to break Homebrew, but they're also not going to halt everything for us.
    - lostcolony 6y ago
      Thanks for calling that out. This is totally unrelated to everything, but it's refreshing to see people giving credit -and thanks- to behemoth companies here on HN, with the proper nuance to also call out places they could have helped more (and the understanding of why they didn't). It's too easy, and common, to pile on the shortcomings. It struck me as a standout comment even in this generally polite community.
eyjafjallajokul 6y ago
Mate, can you tone it down a little? Your opinion is fine but it’s unnecessarily inflammatory towards basically volunteer work.
one-punch 6y ago
> 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/ https://builtwithnix.org/ [2]: https://news.ycombinator.com/item?id=26038614 https://news.ycombinator.com/item?id=26038614
- novok 6y ago
  When I tried nix on my mac a while back, it took forever to install basic things, had very verbose logs, was far more complicated and was missing packages. Is it still like that?
  - ris 6y ago
    Nix on macos only got a pre-built binary cache a couple of years ago - before that, yes, almost everything had to be built from the ground up.
  - soraminazuki 6y ago
    Not my experience at all.
upbeat_general 6y ago
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.
jacobsenscott 6y ago
brew is an amazing achievement. It doesn't do random unwanted updates at odd times. It doesn't do anything at all unless you run run it. And it tells you want it will do beforehand. Nobody would have "filled the void" - building software isn't a zero sum game. If someone had something better they would have continued to work on it and it would have "taken over". There, I said it.
- NicolaiS 6y ago
  That is incorrect. Brew will do random upgrades when running `brew install` unless you set the non-default `HOMEBREW_NO_AUTO_UPDATE=1` [1] so every now and then when you brew install something it will e.g. upgrade the python binary from 3.x => 3.(x+1) and break all virtualenvs using symlinks. Python is just one example, I've spend countless time fixing random broken packages due to the unpredictability of `brew install`. [1] https://github.com/Homebrew/brew/issues/1670 https://github.com/Homebrew/brew/issues/1670
  - jacobsenscott 6y ago
    This is just a misunderstanding of how brew works. Brew is doing what it is designed to do. Your assumptions are that brew should be able to "pin" a package to an exact version, or that it is selecting packages at random to upgrade, but those assumptions are wrong. https://docs.brew.sh/FAQ#why-does-brew-upgrade-formula-also-upgrade-a-bunch-of-other-stuff https://docs.brew.sh/FAQ#why-does-brew-upgrade-formula-also-... However brew does support your use case, but it take some extra effort. If you want to use brew to install an exact version of python you need to create a tap: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap Also, you aren't forced to use brew to install that version of python. You can do so yourself using the standard make; make install. It would be best to install it under /opt. Or use any other available method of installing software on your mac.
brailsafe 6y ago
This seems like a rather exceptional, unsubstantiated, and mean spirited take. I've run into some strange issues with brew over the years, but compared to npm and apt it's been far less prone to causing me headaches.

gagarine 6y ago

I rage quit Homebrew to MacPorts. No complain after 2 years. Not a single bug. Installation are much faster than 10 years ago too (macports use pre-compiled binaries now). Give it a try if you have some time to lose.

smoldesu 6y ago

I agree with you wholeheartedly. Homebrew was my least favorite part of the MacOS experience, which is a shame since it was basically the most important piece of software I had installed on that thing.

my123 6y ago

MacPorts meanwhile existed years before Homebrew, and is alive and well.

yardie 6y ago

Macports? They’ve been around even longer than brew. But they were always a bit too Linuxy for most Mac users.

flemhans 6y ago
I always thought that brew was the "Linuxy" one and Macports was FreeBSD Ports for the Mac.
- sirn 6y ago
  Jordan Hubbard was involved in the creation of both FreeBSD Ports and MacPorts (DarwinPort), so it makes sense that it shares the BSD ways of doing things. His decision to use Tcl for MacPorts also came from his experience dealing with Makefiles[1] [1]: https://netbsd.org/gallery/10years.html#hubbard https://netbsd.org/gallery/10years.html#hubbard
- yardie 6y ago
  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 and I only have HB installed. Since most packages are on HB I no longer need to have both installed.
  - sirn 6y ago
    > 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.
    - LiberatedLlama 6y ago
      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
      - sirn 6y ago
        That's fair, but it's only affecting single user, while writable /usr/local affects all users. However most Mac users are single user, so the tradeoff makes sense in this context.
eecc 6y ago
Linux? Macports take direct inspiration from FreeBSD ports

deleted 6y ago

[deleted]

qntty 6y ago

What do you mean by random unwanted updates? As far as I know, the only way to update is by running brew upgrade.

regulation_d 6y ago
one time i ran “brew upgrade ffmpeg” which somehow forced a major version bump of postgres.
- deleted 6y ago
  [deleted]
- juandazapata 6y ago
  I installed awscli and somehow emacs ended up installed in my system.
w0m 6y ago
Personally; only issue i tend to have is that when I install X, it breaks Y forcing reinstallation of ~everything. What should be a small install ends up taking 30m of cleanup. Entirely likely it's user error on my part; but also problem I haven't really had with other 'nix package managers.
- deleted 6y ago
  [deleted]
- Doctor_Fegg 6y ago
  Which isn't funny when Y is Postgres and your database is no longer readable post-upgrade. Happened to me.
stonesweep 6y ago
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 now have to recompile/upgrade (depending on details) A, B and C as well to use the newly updated version of Y. Arch (and other rolling releases) do/does this every day, it's just that the work is offloaded to upstream packagers. 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.

martpie 6y ago

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 appreciate it be productive and build awesome tools with it.

w0m 6y ago
> What prevents you to do it better then? What prevent you from forking it? Sharing improvement ideas? Contributing to the project? I think ~everything he stated is generally assumed true. I use Brew installed software every single day, and appreciate it. That doesn't put it above criticism though.
- bastardoperator 6y ago
  There is no criticism in their statement though, just a generalized opinion/rant that doesn't point out single issue and is factually inaccurate.
  - zimpenfish 6y ago
    > doesn't point out single issue > is factually inaccurate. I think these two might be somewhat contradictory.
    - bastardoperator 6y ago
      I don't, he said someone else would have filled the void, there was no void considering this project came after macports and fink
- bakedbeanz 6y ago
  "brew fucking sucks" is just whining, not reasonable criticism IMHO
6y ago

Gelob 6y ago

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

dylan604 6y ago
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"?
- wpm 6y ago
  No, I don’t like forced 5 minute stops to my work. Yes, I’m the type of person who only updates on my schedule when notified, or when I need something. These little tools installed by home brew aren’t just little tools, they’re dependencies for whatever else they’re used in. The fact that I need package “X” doesn’t mean I want package Y, something entirely unrelated, updated without my consent. It’s MY fucking computer. Let ME decide what software gets installed on it and when.
- ratww 6y ago
  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.
- eknkc 6y ago
  I generally don't do an apt update before installing a package that I needed at that moment. However I do full update / upgrades when it is convenient for me. That's the point.
- Schalter 6y ago
  I have the same issue and for me there is a simple difference: I probably use homebrew for a handfull of tools, in debian etc. my packagetmanager manages everything. Its not a huge issue but the thought of 'ah shit i need to run update' comes with 'that will be slow'
6y ago

kspacewalk2 6y ago

"Someone else would have filled the void if homebrew hadn’t shown up, and it would hopefully have been better." MacPorts and fink existed before homebrew took over, and they weren't better. That's why homebrew took over.

quesera 6y ago
But Homebrew wasn't (and isn't) better than MacPorts, either. They both work well (we can and do quibble about the internal mechanics of each), and appeal to different groups of people. My theory is that Homebrew was announced at exactly the right time in the MacOS adoption curve. A huge number of new users arrived with no existing knowledge of MacPorts or Fink. Most of them didn't know they needed a package manager at first, but when the momentum picked up, Homebrew was the new option with a better web page, a more collaborative working model, and hosted at GitHub (also ascendant). I'd also argue that similar factors were involved in Linux's popularity over BSD in the 1990s. Timing, environment, adequacy, and luck. All are required. Superiority is not.
- volta83 6y ago
  I used MacPorts before hombrew. Homebrew "just worked", MacPorts sucked. Maybe I was too dumb to use MacPorts, but all other MacPort used I knew back then all moved to homebrew very quickly.
  - thaeli 6y ago
    This, so much this. I tried to use MacPorts. It was pulling teeth every time. Brew was a It Just Works breath of fresh air. I agree that it's a very opinionated tool, and note that those opinions fit in well with the Mac ecosystem. They aren't as good a fit for Linux or Windows.
    - novok 6y ago
      I think often 'it just works' and 'opinionated' goes hand in hand. Without choosing what to say no to, you create infinite workload with finite amounts of people and thus something breaks, somewhere.

throw0101a 6y ago

Besides the already-mentioned MacPorts, NetBSD's pkgsrc is multi-platform, including macOS (AFAICT): * https://www.pkgsrc.org/ https://www.pkgsrc.org/

smazga 6y ago
Yeah, it works on macOS and is actually very nice, but its package catalog is not quite as comprehensive and OS upgrades are a huge headache. In other words, a solid alternative with a different set of issues.
jperkin 6y ago
macOS users may want to use my binary package repository, updated every few days from pkgsrc trunk: https://pkgsrc.joyent.com/install-on-osx/ https://pkgsrc.joyent.com/install-on-osx/

game_the0ry 6y ago

I am cool with constructive criticism, but you do realize brew is free, right? If you are not happy with open source, you have a couple of options: - build your own brew - brew is open source, so you can make contributions to improve - pay for something like brew (though probably not an option for brew) Have you done any of the above before complaining? I am guessing - no. Otherwise, say "thank you" and move on, my friend.

Enginerrrd 6y ago
I get where you're coming from, but I think the open source community benefits from being, well, open. Walling yourself off from user frustrations and criticism with the attitude that they are ungrateful is not how projects evolve to better meet user needs.
oreille 6y ago
You sure sound absolutely cool with criticism.
dmitriid 6y ago
Being free doesn't absolve it of criticism.

loriverkutya 6y ago

When I get angry about brew sucks I always remind myself there is npm.

cmehdy 6y ago
When I get angry about npm, I remind myself there is gradle.
- Gaelan 6y ago
  When I get angry about gradle, I remind myself there is autotools.
  - deleted 6y ago
    [deleted]

paultopia 6y ago

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.

Hamuko 6y ago
>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/b18f104f14350b58b9d6d5b8280af073327bf0b8 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.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- kemayo 6y ago
  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.

deleted 6y ago

[deleted]

volta83 6y ago

> There, I said it. What a waste of bytes and bandwidth. "[homebrew] It’s the worst package manager I’ve used" is true for all users that have only used one package manager. The opposite claim ("it's the best I've used") would simultaneously be true. You could at least have mentioned _why_ and that could have kickstarted a meaningful discussion, but instead your comment is the equivalent on a thumbs down in a youtube video.

anaerobicover 6y ago
Pot, meet kettle: https://news.ycombinator.com/item?id=26037357 https://news.ycombinator.com/item?id=26037357 > volta83 1 hour ago | parent [–] | on: Homebrew 3.0 > I used MacPorts before hombrew. Homebrew "just worked", MacPorts sucked. > Maybe I was too dumb to use MacPorts, but all other MacPort used I knew back then all moved to homebrew very quickly. > reply

tomlin 6y ago

If you've used Valet, you know truly that Brew is the worst.

deleted 6y ago

[deleted]

prpl 6y ago

It might not cover everything, but it also has a superset of other things more - conda + conda-forge (with mamba too for better performance) The had also apple silicon support for many things more than a month ago.

onedognight 6y ago

export HOMEBREW_NO_AUTO_UPDATE=1

filleduchaos 6y ago
That doesn't solve the evergreen packages problem, and I'm tired of people trotting out this flag when people (rightfully in my opinion) complain about brew upgrading literally everything it can get its hands on.

woodruffw 6y ago

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 bugtracker on some random domain, and thus receives direct community support volume that we need to address. 2. Homebrew is not an official system package manager. 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. Many of our changes over the last decade (installing our own Ruby, rolling back custom source options) can be directly traced back to changes that Apple imposes that produce disproportionately greater maintenance effort from us.

jedbrown 6y ago
Point 2 here is huge. If Apple cared about open source or cross-platform developers, they would pay at least one full-time Homebrew developer and upgrades would be smooth. It speaks volumes that they are swimming in money and can't be bothered to make a token gesture.
- woodruffw 6y ago
  > It speaks volumes that they are swimming in money and can't be bothered to make a token gesture. I agree with a lot of the sentiment here, but I want to make one important correction: Apple has helped us. In particular, they gave us access to DTKs for the M1 and provided us with a liaison for the migration. We're very thankful for that help. That being said, Apple is a massive company and they have their own development goals and velocity for macOS. They're not actively looking to break Homebrew, but they're also not going to halt everything for us.
  - lostcolony 6y ago
    Thanks for calling that out. This is totally unrelated to everything, but it's refreshing to see people giving credit -and thanks- to behemoth companies here on HN, with the proper nuance to also call out places they could have helped more (and the understanding of why they didn't). It's too easy, and common, to pile on the shortcomings. It struck me as a standout comment even in this generally polite community.

eyjafjallajokul 6y ago

Mate, can you tone it down a little? Your opinion is fine but it’s unnecessarily inflammatory towards basically volunteer work.

one-punch 6y ago

> 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/ https://builtwithnix.org/ [2]: https://news.ycombinator.com/item?id=26038614 https://news.ycombinator.com/item?id=26038614

novok 6y ago
When I tried nix on my mac a while back, it took forever to install basic things, had very verbose logs, was far more complicated and was missing packages. Is it still like that?
- ris 6y ago
  Nix on macos only got a pre-built binary cache a couple of years ago - before that, yes, almost everything had to be built from the ground up.
- soraminazuki 6y ago
  Not my experience at all.

upbeat_general 6y ago

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.

jacobsenscott 6y ago

brew is an amazing achievement. It doesn't do random unwanted updates at odd times. It doesn't do anything at all unless you run run it. And it tells you want it will do beforehand. Nobody would have "filled the void" - building software isn't a zero sum game. If someone had something better they would have continued to work on it and it would have "taken over". There, I said it.

NicolaiS 6y ago
That is incorrect. Brew will do random upgrades when running `brew install` unless you set the non-default `HOMEBREW_NO_AUTO_UPDATE=1` [1] so every now and then when you brew install something it will e.g. upgrade the python binary from 3.x => 3.(x+1) and break all virtualenvs using symlinks. Python is just one example, I've spend countless time fixing random broken packages due to the unpredictability of `brew install`. [1] https://github.com/Homebrew/brew/issues/1670 https://github.com/Homebrew/brew/issues/1670
- jacobsenscott 6y ago
  This is just a misunderstanding of how brew works. Brew is doing what it is designed to do. Your assumptions are that brew should be able to "pin" a package to an exact version, or that it is selecting packages at random to upgrade, but those assumptions are wrong. https://docs.brew.sh/FAQ#why-does-brew-upgrade-formula-also-upgrade-a-bunch-of-other-stuff https://docs.brew.sh/FAQ#why-does-brew-upgrade-formula-also-... However brew does support your use case, but it take some extra effort. If you want to use brew to install an exact version of python you need to create a tap: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap Also, you aren't forced to use brew to install that version of python. You can do so yourself using the standard make; make install. It would be best to install it under /opt. Or use any other available method of installing software on your mac.

brailsafe 6y ago

This seems like a rather exceptional, unsubstantiated, and mean spirited take. I've run into some strange issues with brew over the years, but compared to npm and apt it's been far less prone to causing me headaches.