10 ms·

Brew Is a Bad Neighbor

134 points by zdw 4y ago

sgammon 4y ago
- pxc 4y ago
  Despite the title, the OP is not a rant, but a guide to using Homebrew in a more broadly compatible and self-contained way.
  - happyopossum 4y ago
    It is a guide, but it is also a rant. You can’t intersperse passive-aggressive, angry, and condescending comments throughout a guide and not expect people to call it a rant.
    - pxc 4y ago
      Either way, it doesn't make much sense to expect a 'clapback' so much as a statement like > Some users would prefer tradeoffs other than those Homebrew has selected with its defaults. Happily, such users can take steps as outlined in this guide, and use Homebrew on a way more to their liking.
      - sgammon 4y ago
        max clapped back at Google, so i don't know why he would feel unable to clap back at this. if i were max, i would certainly point out how hard Apple's security sandbox and other features make his job. i am not sure a brilliant engineer like max would intentionally build in these rough edges. tradeoff decisions are difficult, we all know that, and so, judging someone's outcomes without the inputs is foolish.
amelius 4y ago
IT seems to be stuck in an endless loop of package management/versioning/install problems.
- dima55 4y ago
  If you use an OS that doesn't do package management, maybe. Linux distros work just fine.
  - IshKebab 4y ago
    As long as you only ever use packages from your distro's packaging system.
  - adhesive_wombat 4y ago
    Until you have something that uses conda.
  - bzxcvbn 4y ago
    The existence of nix, nvm, conda, venv... or even docker suggests otherwise.
    - oneplane 4y ago
      Out of that list, only nix is a system package manager. The rest are developer tools and runtime configurations.
      - aprdm 4y ago
        How is conda different than nix in this regard?
        oneplane 4y ago
        Conda is a subset of Nix in this regard.
      - bscphil 4y ago
blindseer 4y ago
I did something like this a long time ago, and installing clang, gcc or ghc took FOREVER. I think I spent a whole day trying to install qmk just because various things required compiling. Granted my computer is old (MBP 2012). I'm not sure it is worth the trouble. Can someone explain to me why I shouldn't just "trust" that the homebrew developers and maintainers know what they are doing and just have it installed in the default location? I get the theoretically I'm more susceptible to accidentally running a script that requires sudo, but are they any other downsides?
- monkellipse 4y ago
  Unexpected overwrites of system tools are the problem I’ve faced. Not sure how common that really is but once can be enough to leave a bad taste!
  - oneplane 4y ago
    On SIP-enabled systems that can't really be done anymore. But on Linux (LinuxBrew) that can definitely happen. The brew link system is supposed to help with that, but there are no guarantees.
    - mdaniel 4y ago
      As someone who runs Linuxbrew, I can assure you it does no such thing unless someone is misguided enough to have "NOPASSWD: ALL" in sudoers. Filesystem permissions didn't magically stop existing because Linuxbrew showed up, and it does not use any setuid binaries
      - oneplane 4y ago
        Keep in mind that /usr/local might contain user-created files and directories and might not have their permissions set strictly like other system directories. If you create something in there and then run brew, your normal user permissions are enough to silently overwrite things. That said, brew is (usually) smart enough to notice if a file already exists, and it will simply leave it be and prompt the user. The problem at that point is that the force link command works without sudo and will happily overwrite anything with a symlink to the Cellar-installed version.
RodgerTheGreat 4y ago
From the title, I expected a mention of brew's telemetry (which can be opted out of, but are broadcast by default): https://github.com/Homebrew/brew/blob/master/docs/Analytics.md https://github.com/Homebrew/brew/blob/master/docs/Analytics....
monkellipse 4y ago
I really got fed up with Homebrew after something got clobbered, this looks like a nice simple solution to that! Thanks! Curious to know how effective it is in practice. I resorted to abusing Docker for nifty command line tricks on the Mac but it sure is a heavy solution and some things really are better on the metal!
hk1337 4y ago
yeah, I have had Homebrew installed under ~/.brew for quite awhile. I don't really like that idea of it out in /usr/local for one but it also helps with permissions as Apple "secures" the OS with each update.
hosh 4y ago
I abandoned brew for asdf. And then a new coworker introduced nix. The kind of issues I get with brew just isn’t there when using nix. I still don’t know how to write nix expressions, but I don’t really see any reason to go back to using brew.
- teg4n_ 4y ago
  What does asdf have to do with package management? It’s only a version manager as far as I know and one of the suggested ways to install asdf is to install it with brew
  - hosh 4y ago
    That's a pretty narrow idea of a "package manager" if you don't consider a version manager to also be a kind of package manager. It's more accurate to say that asdf does not comprehensively provide as many software that brew provides, and asdf does not manage library dependencies. What asdf does that brew is very crappy at is being able to run things in isolation from the home directory, and being able to run specific versions of a software. asdf installs things in the home directory by default, and so for the software it does have in its repos, it was something I use instead of brew. Besides, you missed the part I wrote about nix. Even with a higher learning curve, nix does the things brew and asdf don't do well. It provides package management, library dependency management, can run things from the home directory, can have multiple versions running, and works with direnv to autoload the correct software based on the current directory.
- gonehome 4y ago
  I’m 0 for 2 so far trying to get stuff built with nix working on an M1 machine (for open source projects that use it). Maybe I’m doing something wrong, but my personal experience with it so far has been bad.
  - hosh 4y ago
    Same here, though my coworker got it working on an M1. I use a cloud Linux box and nix has been working great there.
FiloSottile 4y ago
> "huh, maybe it's not great my executables are writeable by my account without requiring authorization first" I'm very confused as to what threat model leads to this concern on an unsandboxed (predominantly) single-user desktop OS such as macOS.
- still_grokking 4y ago
  https://xkcd.com/1200/ https://xkcd.com/1200/
  - FullyFunctional 4y ago
    That's exactly it, except it's worse in that every time you run an application, you are essentially letting the code author do anything as you on your machine (obvious, but worth stating). The only reason this works is because we trust "people" to discover this and fix it (and it will usually have consequences for the perpetrator). I'm just not sure this model works anymore, just like we don't use telnet, rcp, and all the other things that assumed you could trust the network.
- mdaniel 4y ago
  I would guess the same risk as "npm i" or "pip install": exfiltration of credentials or other supply chain attacks. My greatest threat is not a bitcoin miner but rather taking advantage of the data on my machine that I'd rather not leave my machine
  - acdha 4y ago
    This is orthogonal to that point: if I can run code as you, I can exfiltrate your data or write an exploit anywhere writable. The only case where having Homebrew be read-only matters is on a multiuser system where you can do something as a non-admin user.
- pxc 4y ago
  You're not wrong about the way macOS is typically used, but... I love that the things people will say about macOS include both 'certified Unix' and 'single-user OS'.
leokennis 4y ago
This guide is written like the homebrew people force you at gunpoint to use it. They don’t. If you don’t like homebrew’s defaults and want to write a guide on how to change that, there’s no need to make it sound this aggressive. For most people homebrew is an easy to use solution to install software and its dependencies and keep them up to date.
- manmal 4y ago
  This kind of behavior is an extension of the problematic entitlement towards OSS imo. „Brew is a bad neighbor“ is not a fair description for a free (!) tool that made millions of dev lives easier.
  - tomxor 4y ago
    > not a fair description for a free (!) tool that made millions of dev lives easier. I think part of the problem is for those stuck with Macs, for whatever reason - brew doesn't merely make their life as a dev easier, it makes being a dev possible - which only worsens the sense of entitlement.
    - bardworx 4y ago
      Are you implying you cannot be a dev w/o brew?
      - tomxor 4y ago
        No. I'm saying on MacOS, for certain types of development where you need BSD or GNU userland tools not included in MacOS - a package manager for installing such tools like brew is required to make life sane and workable.
        bardworx 4y ago
        > brew doesn't merely make their life as a dev easier, it makes being a dev possible Your comment made it seemed as if there was no way to develop on a Mac before homebrew, which I think is silly. It’s just a tool. Makes your life easier but that’s it.
theonemind 4y ago
I saw a comment that stuck with me once: "Ruby people don't get root", referring to an unwillingness to trust Ruby tools or the ruby community as it got closer to his system. This rule works surprisingly well.
- treeman79 4y ago
  Its good Practice to never use root for any ruby application. RVM or rbenv with Gemfile do a great job in giving you any version you need and keeping the system clean. Way back in the day you basically had to reverse engineer each developers environment to let another person use it. Now it’s common to grab any semi decent project and be up in running in a couple minutes. Brew usually takes care of any system level stuff. Nokogiri, image magic, etc.
  - NegativeLatency 4y ago
    even just ‘gem install PACKAGE —-user’ will get you pretty far
  - skunkworker 4y ago
    I don’t think I’ve touched system ruby in years. With RVM everything is just installed into my home ~/.rvm folder and keeps it tidy.
- marcosdumay 4y ago
  I try not to use anything in PHP; Python and Ruby are isolated as well as possible (optimally, not having access to my homedir and definitively not getting "installed"); Bash will get thoroughly reviewed for data validation red flags; and I will avoid anything that imposes a code convention and is written in Go. Now I am surprised that I don't have any general rule for C and Java.
- KerrAvon 4y ago
  First rule of Unix security is that no tool should have unnecessary root. Ruby isn’t special in this regard, and Homebrew doesn’t particularly seem to be problematic. I’ve had a lot bigger problems with Python-based tooling, tbh, but I imagine it’s the developers and not the language.
goranmoomin 4y ago
Or instead of all this, try MacPorts[0], which in my experience has 99% of what you need. The biggest drawbacks are less support from quite niche packages (the ones that sets up its own homebrew tap), and a bit slower updates. But then I found it bearable much more than homebrew’s downsides. [0]: https://macports.org https://macports.org
- oneplane 4y ago
  The Gist's contents apply to macports too, but instead of only clobbering /usr/local or /opt it does both.
  - pcr910303 4y ago
    Hmm… can you elaborate? AFAIK MacPorts never touches outside /opt/local in it’s default configuration, and it requires sudo, so it doesn’t have the finicky permission problems that homebrew had on multiuser systems.
    - oneplane 4y ago
      Back in the PowerPC days (when I used Fink and later switched to MacPorts) it often didn't integrate with any expected paths that were used when building software. This meant that you either have to symlink things in yourself or have a persistent directory symlink to make sure any ports you installed could be picked up by other software. Similar problems happened the other way around if MacPorts was first in your path as your includes couldn't find the system files anymore since it was looking for files relative to the files you found in /opt/local. Regarding the permission problem: have never had any issue, but that's probably because I don't mix multiple users and developer tools.
      - yunohn 4y ago
        You made an unsupported assertion about Macports, based on your experience from “the PowerPC days”? I don’t even use Macports, but that’s just plain unfair.
icedchai 4y ago
I prefer MacPorts, which uses /opt/local by default. /usr/local is for things I build myself / install manually.
- oneplane 4y ago
  Brew uses /opt by default as well (but it wasn't always the case, and it used to symlink into /usr/local too while keeping the actual files in the Cellar).
  - sashk 4y ago
    /opt by default is for M1 and later based Macs. intel based Macs still use /usr/local.
  - mdaniel 4y ago
    Heh, you and I posted about the same time, but it seems that's actually only true for arm64: https://github.com/Homebrew/install/blob/master/install.sh#L130 https://github.com/Homebrew/install/blob/master/install.sh#L...
  - icedchai 4y ago
    Good to know. Last time I used brew was on an Intel Mac.
- mdaniel 4y ago
  I was going to say that recent installs have switched to /opt/Homebrew, but while digging up supporting evidence I noticed that they bizarrely only do that for arm64 installs: https://github.com/Homebrew/install/blob/master/install.sh#L130 https://github.com/Homebrew/install/blob/master/install.sh#L...
  - duskwuff 4y ago
    Changing the install prefix for a project like Homebrew is hard, because directory names frequently get embedded in executables and configuration files. The ARM migration was a convenient time to make the switchover, because everything had to be rebuilt anyway.
Aloha 4y ago
why should I care if its in /usr/local or /opt I thought that those are the standard place to put third party unix software?
- jlg23 4y ago
  From the article: > Since it was installed in your home directory - no need to change any permissions. No sudo required. Although I'd argue sudo vs no-sudo-but-in-your-home-directory is the same difference. Local exploits are trivial to find, plentiful and still not even necessary: 99% of the time some sloppy local configuration can be exploited to gain root access. I've switched to "let's try a few minutes on our own before asking the admin" a long time ago - and haven't required an admin's help ever since..
- clhodapp 4y ago
  /usr/local is supposed to be kind of a "standard Unix tree" (with like bin & share directories and the like) that contains software manually installed by the system administrator, for the use of all users, possibly from multiple sources / by multiple techniques. If one source of software or user takes over the whole thing, they are muscling out all the other valid use cases for that tree. /opt is supposed to be a place where programs that don't want to co-operate are granted ownership of one directory to install stuff in, which they can organize as they wish. It's often used as a way to install badly-packaged proprietary software or to give "foreign" package managers a place to put their packages. Brew wanting to take over /usr/local is kind of like a package manager wanting to take over the whole /opt. It's overstepping its bounds.
DominoTree 4y ago
FWIW, using the `--force-bottle` flag will force homebrew to install its existing pre-built packages into a non-standard path you've configured instead of compiling them from scratch, and I've never run into an issue with a package doing it that way.
ricardobeat 4y ago
> a package management system that will literally yell at you if you try to do something about "huh, maybe it's not great my executables are writeable by my account without requiring authorization first" I assume “asking for authorization” means sudo. That’s a lot more dangerous, since installers can then modify anything on your system, this is the reason homebrew is set up to avoid it.
- DavideNL 4y ago
  Note that you could just setup/run brew as another Admin useraccount (without using sudo.) So from your main non-Admin account you can then do `su - myadminuser` to then run `brew install vim`, etc.
  - ricardobeat 4y ago
    Won't this alternative admin account also have access to the entire filesystem during installs?
    - DavideNL 4y ago
      The point is; First of all, the standard (non-admin) user can't directly write to/change brew files. So neither can all the apps you run. You'd first have to change to the admin user with `su - myadminuser`. An admin user does not equal the 'root' user, which has even more permissions. You still have to first `sudo -i` as the admin user, to become root (which is not needed for brew.)
rvieira 4y ago
I've always used brew, but sometime in the last few of years (Mojave?) I was plagued with these problems when installing different versions of Python simultaneously. Either brew broke Python installs, broke things like asdf, couldn't build Python from scratch, virtualenvs broke. Hair-pulling stuff. I decided to use MacPorts just for Python and switching Python versions worked perfectly. Eventually I migrated most of the brew stuff to MacPorts. I'm not saying one is superior to another, it's just that in my very personal experience and uses, I don't find anything in brew that MacPorts doesn't give me.
- b3morales 4y ago
  It's been a while since I've looked into it, but last I knew MacPorts was much more aggressive than brew about just not sharing dependencies between packages, to avoid this kind of thing. In effect, trading disk space against fragility.
- NegativeLatency 4y ago
  asdf has been nice for managing programming language versions
- rcarmo 4y ago
  I use brew with pyenv and never looked back.
- chrisfinazzo 4y ago
  Like rcarmo, I looked at pyenv as it shared (Read: copied wholesale for obvious reasons) many of the ideas in rbenv which has been excellent for dealing with different versions of Ruby. Either I just couldn't get used to it or the similarities are not as clear as they might appear to be at first glance because I eventually gave up and backed off Python entirely until miniconda was available via brew and BBEdit gained the ability to switch environments without jumping through hoops. That said, I am currently trying to remove Python from brew entirely and put everything into conda - for a few upgrades now, brew has complained loudly during upgrades that compiling from source isn't supported and may break things. I can run `brew uses $FORMULA` to find the things that depend on Python that brew knows about - is it generally safe to move these into conda's "base" environment? The main thing that I use conda for (The Standard Ebooks project) has an environment and version of Py all to itself.
zenlf 4y ago
I clicked on this and expected something really bad about brew. It turns out just the default setting doesn’t satisfy the writer’s use case. The energy and attitude of this article really sticks me as odd especially considering Brew is free to use and not some sort of default package manager that comes with your macOS. If you want to write a guide to do something, great. You contribute to the collective knowledge base, but there is absolutely no need having this combative attitude towards somebody are doing the same.
- iepathos 4y ago
  Yeah, I was surprised the author had an issue with using /opt since that's the expected location in *nix for the installation of add-on application software packages. Maybe he's running a multi-user machine and really wants brew in his home directory for that reason.
  - nerdponx 4y ago
    If anything, Brew going in /opt makes a whole lot more sense than the old default of /usr/local. Supporting individual per-user installs in the home directory would be really nice of course, but I guess that's just not something they intend to support (it's offered on Linux on the "you are on your own, good luck" basis).
    - craigching 4y ago
      Agreed. When brew installed in /usr/local I ranted much like this post. I’m much happier with brew since the move to /opt.
- nerdponx 4y ago
  I think it's "cool" in some circle to hate on Homebrew. It's not my favorite piece of software (I prefer MacPorts), but it's improved a lot over the years and its existence does a lot of good for a hell of a lot of people.
- Decker87 4y ago
  It's what gets the clicks.
jxi 4y ago
Casks still need root to install apps into /Applications
racl101 4y ago
I've never hated a package manager more.
- kdtsh 4y ago
  Hate is such a strong feeling to have towards a package manager. I don’t see how a freely built, freely available tool that you don’t have to use could cause such negative feelings, but if you just don’t use it then you’ll get over it.
  - racl101 4y ago
    Heh, yeah I get what you're saying. Sounds overtly dramatic. But let me explain: I don't use it personally. I prefer to use virtual machines or Docker for my own workstation. But I am in a position to have to troubleshoot other people's Macbooks with this package manager ... so yeah. I stand by what I said. I wouldn't mind if other people troubleshooted their own stations at work.
    - kdtsh 4y ago
      Fair enough, if a user is maintaining packages on their computer with Homebrew I feel like they should take some responsibility for that. Unless it’s a cask, they should figure it out themselves or you can only really provide your best efforts. If you use a third-party package manager you should learn to be comfortable and familiar with how it works, or at least with how packages are declared, so you can troubleshoot your own problems and if necessary raise issues on the project.
FullyFunctional 4y ago
I have mixed feelings about brew; it’s very convenient but the one time I reported a bug I instantly got banned and yelled at because of my wording. It was very one-sided as I wasn’t able to apologize or even explain due to the insta-ban. My one other interaction with brew community was similar; absolutely any critique is taken as a holy war. I’d really rather Apple made it unnecessary to plug this hole and render brew redundant. ADD: for the record my “offense” was saying “Are you for real?” when they screwed up and reverted back to an ancient version. I was shocked by that lack of QA but sure, I could have said it better. Still, cancel culture meant the end of that conversation.
- TillE 4y ago
  > for the record my “offense” was saying “Are you for real?” when they screwed up It's really not hard to just not be a jerk, even when someone else has made a mistake. Just be kind. Or at the very least, be calm and factual and nothing else. It makes everyone's lives a little better, including your own.
  - FullyFunctional 4y ago
    Hindsight is so easy and I wanted to apologize, but wasn’t allowed. It was certainly taken as more offensive than I had intended and I realized that, but too late.
  - userbinator 4y ago
    It says a lot that you perceive such a short and IMHO well-deserved expression of frustration as "being a jerk". If I was on the receiving end of that, I would only apologise as being the one at fault. That's what defuses the situation instead of aggravating it. It makes everyone's lives a little better, including your own. No it doesn't. This "forced positivity" is far worse in the long term.
    - acdha 4y ago
      Another way of thinking about it: Homebrew is a volunteer project which tons of people depend on for work but don't contribute to. If the volunteers get a ton of low-value comments from people who are talking like they have a support contract, blocking those people is a way of protecting the volunteers. I may not like it as the ideal outcome but I prefer that maintainers don't burn out, too.
password4321 4y ago
I quit using homebrew after the auto-update-everything kicked in as part of installing some new tiny utility. Both Apple and homebrew had transitioned away from supporting my OS recently... several working versions of software were uninstalled, then something failed to build, leaving behind a total disaster. I wouldn't even consider using it again without HOMEBREW_NO_AUTO_UPDATE=1. MacPorts has been good to me, it even has an ncdu1 package since Zig doesn't support legacy macOS either. Ask HN: Best Alternative to Homebrew in 2021? https://news.ycombinator.com/item?id=29079096 https://news.ycombinator.com/item?id=29079096
- laserlight 4y ago
  I wonder who thought the autoupdate is a good idea. It's absolutely crazy. Lots of things break down and some of them do silently, making it really difficult to find the problem when one discovers it days or weeks after the autoupdate.
  - acdha 4y ago
    On a clean system it’s rare to have things break so if you’re an open source developer you prefer people use the current release of something rather than re-reporting bugs you fixed 3 years ago.
- hparadiz 4y ago
  Thank you for this little bit of sanity.
- pgorczak 4y ago
  Seconding this, I have lots of Python virtual environments with packages that link to brew libs. It’s a bummer coming back to an env after a while and then realizing auto update has removed linked files due to a minor version bump
- rjzzleep 4y ago
  I used gentoo prefix for a long time and it was a much much better citizen than homebrew(which isn't hard TBH). But gentoo has a terrible way of engaging the community. I tried to contribute but it was just cumbersome. So in the end back in the days I still had my own clang patches(basically before all the apple changes were upstreamed).
spaceywilly 4y ago
>homebrew (grudgingly?) supports being installed in a non-standard folder. They just don't suggest it to you up front. It's tucked away in the detailed installation page under "Alternative Installs" Oh good, another user of an open source project expecting the devs to support their special setup, while (presumably) not contributing anything back.
- guimplen 4y ago
  Your comment would be relevant if the guy written something to the devs. He has a sacred right to rant on his own page as he likes.
  - spaceywilly 4y ago
    But his rant could’ve easily been a pull request in the Brew repo. Would’ve taken just as much (maybe even less) than what he did to come up with his own solution. Let’s say he added a —sandbox option to the home brew install script that did all this automatically. Now it benefits everyone using homebrew. The whole tone of the article is pretty hostile and childish, which is a toxic attitude in my opinion. Better to be cooperative and help out the community.
pxc 4y ago
What the OP describes is how I use Homebrew on macOS: non-standard prefix, not on the PATH. The other thing I do is use it exclusively for 'Casks' (pre-built .app bundles distributed as .dmg or .pkg). If you do this, you can use any combination of Nix, pkgsrc, and MacPorts for your traditional Unix-y package needs.
jordemort 4y ago
I used to be cranky about it taking over /usr/local but since I upgraded to an M1 I have no problem with it hanging out in /opt. I don’t understand why the path switched when the architecture did but I’m happy about the change.
- frizlab 4y ago
  I think it’s easier to maintain the bottles for two different architectures at two different paths, and the /usr/local path take over was a recurrent complaint, so the devs took advantage of the new arch to change the path.
  - Hackbraten 4y ago
    Ex-Homebrew maintainer here. You’re correct. I couldn’t have explained it better.
- fijiaarone 4y ago
  Brew moving to /opt was nice on M1 but nothing being able to compile on M1 is a bit inconvenient. But that’s not brew’s fault.
  - mdaniel 4y ago
    I mean, that can't possibly be true, right? The bottles don't appear out of nowhere. So "brew install --build-from-source bash" dies for you?
  - jordemort 4y ago
    Not sure if your issue is brew-specific, I've compiled plenty of stuff since getting my M1
- acdha 4y ago
  No legacy systems meant they didn’t have to worry about whining when they switched since everyone was by definition using a new install.
orliesaurus 4y ago
I use brew all the time, and I found the title of this article was super-negative for no reason?
OrderlyTiamat 4y ago
Is there a guide like this for anaconda? I'd really prefer to have it "shoved into its own little corner " without it touching my bashrc and the like. I'm currently isntalling it with nix-env, which is great, but nix is a tad overkill, and if/when I'm done experimenting with nix, I'd like to have a way to use conda for projects that require it, but have it otherwise leave me the hell alone.
OrderlyTiamat 4y ago
Is there a guide like this for anaconda? I'd really prefer to have it "shoved into its own little corner " without it touching my bashrc and the like. I'm currently isntalling it with nix-env, which is great, but nix is a tad overkill, and if/when I'm done experimenting with nix I'll still probably require conda.
skybrian 4y ago
I have less of a problem with Brew and more with installation procedures that require Brew. For example, instructions for using the Raspberry Pi Pico C SDK typically start with "brew install cmake". CMake itself supports Mac OS 10.10 or later. Brew requires 10.15, so if you depend on CMake via Brew then you're cutting off people with older systems. Furthermore, trying to install via brew means you'll pull in other unnecessary dependencies. It tried to install Python for some reason but failed. (Python itself supports Mac 10.11 or later, but Brew apparently tries some other way of doing it.) Yes, I should buy a newer machine, but many other programming tools work fine.
- alexjurkiewicz 4y ago
  10.10 has been eol for five years without security updates. How long should downstream tools support an eol OS?
  - skybrian 4y ago
    I'd guess CMake supports it just because they haven't seen a reason to require a newer version yet. Command line tools are like that. (The Go SDK requires 10.13.) That's the difference between what people can do for individual tools versus an entire ecosystem like Brew that's trying to do everything.
FullyFunctional 4y ago
My worry with brew and literally any software installed from "random" sources is that I don't want to trust it, but it runs with all my credentials and can do just about anything on my behalf. When using, say, macOS or Ubuntu, I have made the deliberate decision to trust the vendor to not be subversive, but as soon as you bring in outside sources you expose yourself. This isn't an academic concern, Log4J and the ongoing phishing attacks on PyPI are good reminders. Apple at least seems to be taking it seriously and has started requiring explicit authorization to access various locations (like Photos), but treats the shell as single security domain, so it's (AFAICT) a global setting for brew installed binaries. For Linux I don't know of anything similar. Obviously there are many things one can do but it needs to be the default and it needs to be not so inconvenient that people just turns it off (hello Microsoft Vista's UAC). What are the solutions here?
- kdtsh 4y ago
  SELinux or AppArmor provide MAC if that’s what you’re looking for.
deleted 4y ago
[deleted]
watersb 4y ago
Also: tools that insist on crapping on my shell environment, `.{bash,zsh}rc` or `.profile` -- I like SourceTree [0] (to unfairly call out just one example), and while I'm aware of alternatives, it's cross platform, available to me without $$ payment ... but it is convinced that it cannot work without adding a block of code to my shell config. @OrderlyTiamat mentions Python world Anaconda https://news.ycombinator.com/item?id=32706193 https://news.ycombinator.com/item?id=32706193 @acdna acknowledges the more general idea of namespace pollution but if I'm reading it right, doesn't think it's a security issue particular to HomeBrew https://news.ycombinator.com/item?id=32707109 https://news.ycombinator.com/item?id=32707109 I can agree that taking over a namespace in the $PATH adds cognitive load to security vigilance, but I can accept that this is standard POSIX reality... But I don't like it when tools add to my $PATH - and then edit my config files in addition to that. I happen to like the UNIX way of filesystem structure for configuration. Re-writing my configuration on program launch takes away that very UNIX strength of composable tools and text files. [0] SourceTree: a nice Git GUI with `.ssh` integration -- https://www.sourcetreeapp.com https://www.sourcetreeapp.com (the ssh keychain is still a problem for me but I've only been trying to fix it for 20 years, and yes I try the nice keychain CLI tool from drobbins and macOS keychain integration and stuffs)
vario 4y ago
there is no alternative better than Brew--and its latest version has very good defaults in place: no need for sudo, everything tucked in a little safe corner, auto-runs update before a new install, and helpful error messages. I don't see why we should be so nitpicking over something that serves us so well.
ElCapitanMarkla 4y ago
I really don’t get all the hate I encounter around brew. I’ve been using it for ~10 years and largely without issue, I certainly wouldn’t say I’ve had less issues with other package managers on Linux etc. That auto update feature they’re flicked on is a pain in the ass though.

134 points by zdw 4y ago

sgammon 4y ago

pxc 4y ago
Despite the title, the OP is not a rant, but a guide to using Homebrew in a more broadly compatible and self-contained way.
- happyopossum 4y ago
  It is a guide, but it is also a rant. You can’t intersperse passive-aggressive, angry, and condescending comments throughout a guide and not expect people to call it a rant.
  - pxc 4y ago
    Either way, it doesn't make much sense to expect a 'clapback' so much as a statement like > Some users would prefer tradeoffs other than those Homebrew has selected with its defaults. Happily, such users can take steps as outlined in this guide, and use Homebrew on a way more to their liking.
    - sgammon 4y ago
      max clapped back at Google, so i don't know why he would feel unable to clap back at this. if i were max, i would certainly point out how hard Apple's security sandbox and other features make his job. i am not sure a brilliant engineer like max would intentionally build in these rough edges. tradeoff decisions are difficult, we all know that, and so, judging someone's outcomes without the inputs is foolish.

amelius 4y ago

IT seems to be stuck in an endless loop of package management/versioning/install problems.

dima55 4y ago
If you use an OS that doesn't do package management, maybe. Linux distros work just fine.
- IshKebab 4y ago
  As long as you only ever use packages from your distro's packaging system.
- adhesive_wombat 4y ago
  Until you have something that uses conda.
- bzxcvbn 4y ago
  The existence of nix, nvm, conda, venv... or even docker suggests otherwise.
  - oneplane 4y ago
    Out of that list, only nix is a system package manager. The rest are developer tools and runtime configurations.
    - aprdm 4y ago
      How is conda different than nix in this regard?
      - oneplane 4y ago
        Conda is a subset of Nix in this regard.
    - bscphil 4y ago

blindseer 4y ago

I did something like this a long time ago, and installing clang, gcc or ghc took FOREVER. I think I spent a whole day trying to install qmk just because various things required compiling. Granted my computer is old (MBP 2012). I'm not sure it is worth the trouble. Can someone explain to me why I shouldn't just "trust" that the homebrew developers and maintainers know what they are doing and just have it installed in the default location? I get the theoretically I'm more susceptible to accidentally running a script that requires sudo, but are they any other downsides?

monkellipse 4y ago
Unexpected overwrites of system tools are the problem I’ve faced. Not sure how common that really is but once can be enough to leave a bad taste!
- oneplane 4y ago
  On SIP-enabled systems that can't really be done anymore. But on Linux (LinuxBrew) that can definitely happen. The brew link system is supposed to help with that, but there are no guarantees.
  - mdaniel 4y ago
    As someone who runs Linuxbrew, I can assure you it does no such thing unless someone is misguided enough to have "NOPASSWD: ALL" in sudoers. Filesystem permissions didn't magically stop existing because Linuxbrew showed up, and it does not use any setuid binaries
    - oneplane 4y ago
      Keep in mind that /usr/local might contain user-created files and directories and might not have their permissions set strictly like other system directories. If you create something in there and then run brew, your normal user permissions are enough to silently overwrite things. That said, brew is (usually) smart enough to notice if a file already exists, and it will simply leave it be and prompt the user. The problem at that point is that the force link command works without sudo and will happily overwrite anything with a symlink to the Cellar-installed version.

RodgerTheGreat 4y ago

From the title, I expected a mention of brew's telemetry (which can be opted out of, but are broadcast by default): https://github.com/Homebrew/brew/blob/master/docs/Analytics.md https://github.com/Homebrew/brew/blob/master/docs/Analytics....

monkellipse 4y ago

I really got fed up with Homebrew after something got clobbered, this looks like a nice simple solution to that! Thanks! Curious to know how effective it is in practice. I resorted to abusing Docker for nifty command line tricks on the Mac but it sure is a heavy solution and some things really are better on the metal!

hk1337 4y ago

yeah, I have had Homebrew installed under ~/.brew for quite awhile. I don't really like that idea of it out in /usr/local for one but it also helps with permissions as Apple "secures" the OS with each update.

hosh 4y ago

I abandoned brew for asdf. And then a new coworker introduced nix. The kind of issues I get with brew just isn’t there when using nix. I still don’t know how to write nix expressions, but I don’t really see any reason to go back to using brew.

teg4n_ 4y ago
What does asdf have to do with package management? It’s only a version manager as far as I know and one of the suggested ways to install asdf is to install it with brew
- hosh 4y ago
  That's a pretty narrow idea of a "package manager" if you don't consider a version manager to also be a kind of package manager. It's more accurate to say that asdf does not comprehensively provide as many software that brew provides, and asdf does not manage library dependencies. What asdf does that brew is very crappy at is being able to run things in isolation from the home directory, and being able to run specific versions of a software. asdf installs things in the home directory by default, and so for the software it does have in its repos, it was something I use instead of brew. Besides, you missed the part I wrote about nix. Even with a higher learning curve, nix does the things brew and asdf don't do well. It provides package management, library dependency management, can run things from the home directory, can have multiple versions running, and works with direnv to autoload the correct software based on the current directory.
gonehome 4y ago
I’m 0 for 2 so far trying to get stuff built with nix working on an M1 machine (for open source projects that use it). Maybe I’m doing something wrong, but my personal experience with it so far has been bad.
- hosh 4y ago
  Same here, though my coworker got it working on an M1. I use a cloud Linux box and nix has been working great there.

FiloSottile 4y ago

> "huh, maybe it's not great my executables are writeable by my account without requiring authorization first" I'm very confused as to what threat model leads to this concern on an unsandboxed (predominantly) single-user desktop OS such as macOS.

still_grokking 4y ago
https://xkcd.com/1200/ https://xkcd.com/1200/
- FullyFunctional 4y ago
  That's exactly it, except it's worse in that every time you run an application, you are essentially letting the code author do anything as you on your machine (obvious, but worth stating). The only reason this works is because we trust "people" to discover this and fix it (and it will usually have consequences for the perpetrator). I'm just not sure this model works anymore, just like we don't use telnet, rcp, and all the other things that assumed you could trust the network.
mdaniel 4y ago
I would guess the same risk as "npm i" or "pip install": exfiltration of credentials or other supply chain attacks. My greatest threat is not a bitcoin miner but rather taking advantage of the data on my machine that I'd rather not leave my machine
- acdha 4y ago
  This is orthogonal to that point: if I can run code as you, I can exfiltrate your data or write an exploit anywhere writable. The only case where having Homebrew be read-only matters is on a multiuser system where you can do something as a non-admin user.
pxc 4y ago
You're not wrong about the way macOS is typically used, but... I love that the things people will say about macOS include both 'certified Unix' and 'single-user OS'.

leokennis 4y ago

This guide is written like the homebrew people force you at gunpoint to use it. They don’t. If you don’t like homebrew’s defaults and want to write a guide on how to change that, there’s no need to make it sound this aggressive. For most people homebrew is an easy to use solution to install software and its dependencies and keep them up to date.

manmal 4y ago
This kind of behavior is an extension of the problematic entitlement towards OSS imo. „Brew is a bad neighbor“ is not a fair description for a free (!) tool that made millions of dev lives easier.
- tomxor 4y ago
  > not a fair description for a free (!) tool that made millions of dev lives easier. I think part of the problem is for those stuck with Macs, for whatever reason - brew doesn't merely make their life as a dev easier, it makes being a dev possible - which only worsens the sense of entitlement.
  - bardworx 4y ago
    Are you implying you cannot be a dev w/o brew?
    - tomxor 4y ago
      No. I'm saying on MacOS, for certain types of development where you need BSD or GNU userland tools not included in MacOS - a package manager for installing such tools like brew is required to make life sane and workable.
      - bardworx 4y ago
        > brew doesn't merely make their life as a dev easier, it makes being a dev possible Your comment made it seemed as if there was no way to develop on a Mac before homebrew, which I think is silly. It’s just a tool. Makes your life easier but that’s it.

theonemind 4y ago

I saw a comment that stuck with me once: "Ruby people don't get root", referring to an unwillingness to trust Ruby tools or the ruby community as it got closer to his system. This rule works surprisingly well.

treeman79 4y ago
Its good Practice to never use root for any ruby application. RVM or rbenv with Gemfile do a great job in giving you any version you need and keeping the system clean. Way back in the day you basically had to reverse engineer each developers environment to let another person use it. Now it’s common to grab any semi decent project and be up in running in a couple minutes. Brew usually takes care of any system level stuff. Nokogiri, image magic, etc.
- NegativeLatency 4y ago
  even just ‘gem install PACKAGE —-user’ will get you pretty far
- skunkworker 4y ago
  I don’t think I’ve touched system ruby in years. With RVM everything is just installed into my home ~/.rvm folder and keeps it tidy.
marcosdumay 4y ago
I try not to use anything in PHP; Python and Ruby are isolated as well as possible (optimally, not having access to my homedir and definitively not getting "installed"); Bash will get thoroughly reviewed for data validation red flags; and I will avoid anything that imposes a code convention and is written in Go. Now I am surprised that I don't have any general rule for C and Java.
KerrAvon 4y ago
First rule of Unix security is that no tool should have unnecessary root. Ruby isn’t special in this regard, and Homebrew doesn’t particularly seem to be problematic. I’ve had a lot bigger problems with Python-based tooling, tbh, but I imagine it’s the developers and not the language.

goranmoomin 4y ago

Or instead of all this, try MacPorts[0], which in my experience has 99% of what you need. The biggest drawbacks are less support from quite niche packages (the ones that sets up its own homebrew tap), and a bit slower updates. But then I found it bearable much more than homebrew’s downsides. [0]: https://macports.org https://macports.org

oneplane 4y ago
The Gist's contents apply to macports too, but instead of only clobbering /usr/local or /opt it does both.
- pcr910303 4y ago
  Hmm… can you elaborate? AFAIK MacPorts never touches outside /opt/local in it’s default configuration, and it requires sudo, so it doesn’t have the finicky permission problems that homebrew had on multiuser systems.
  - oneplane 4y ago
    Back in the PowerPC days (when I used Fink and later switched to MacPorts) it often didn't integrate with any expected paths that were used when building software. This meant that you either have to symlink things in yourself or have a persistent directory symlink to make sure any ports you installed could be picked up by other software. Similar problems happened the other way around if MacPorts was first in your path as your includes couldn't find the system files anymore since it was looking for files relative to the files you found in /opt/local. Regarding the permission problem: have never had any issue, but that's probably because I don't mix multiple users and developer tools.
    - yunohn 4y ago
      You made an unsupported assertion about Macports, based on your experience from “the PowerPC days”? I don’t even use Macports, but that’s just plain unfair.

icedchai 4y ago

I prefer MacPorts, which uses /opt/local by default. /usr/local is for things I build myself / install manually.

oneplane 4y ago
Brew uses /opt by default as well (but it wasn't always the case, and it used to symlink into /usr/local too while keeping the actual files in the Cellar).
- sashk 4y ago
  /opt by default is for M1 and later based Macs. intel based Macs still use /usr/local.
- mdaniel 4y ago
  Heh, you and I posted about the same time, but it seems that's actually only true for arm64: https://github.com/Homebrew/install/blob/master/install.sh#L130 https://github.com/Homebrew/install/blob/master/install.sh#L...
- icedchai 4y ago
  Good to know. Last time I used brew was on an Intel Mac.
mdaniel 4y ago
I was going to say that recent installs have switched to /opt/Homebrew, but while digging up supporting evidence I noticed that they bizarrely only do that for arm64 installs: https://github.com/Homebrew/install/blob/master/install.sh#L130 https://github.com/Homebrew/install/blob/master/install.sh#L...
- duskwuff 4y ago
  Changing the install prefix for a project like Homebrew is hard, because directory names frequently get embedded in executables and configuration files. The ARM migration was a convenient time to make the switchover, because everything had to be rebuilt anyway.

Aloha 4y ago

why should I care if its in /usr/local or /opt I thought that those are the standard place to put third party unix software?

jlg23 4y ago
From the article: > Since it was installed in your home directory - no need to change any permissions. No sudo required. Although I'd argue sudo vs no-sudo-but-in-your-home-directory is the same difference. Local exploits are trivial to find, plentiful and still not even necessary: 99% of the time some sloppy local configuration can be exploited to gain root access. I've switched to "let's try a few minutes on our own before asking the admin" a long time ago - and haven't required an admin's help ever since..
clhodapp 4y ago
/usr/local is supposed to be kind of a "standard Unix tree" (with like bin & share directories and the like) that contains software manually installed by the system administrator, for the use of all users, possibly from multiple sources / by multiple techniques. If one source of software or user takes over the whole thing, they are muscling out all the other valid use cases for that tree. /opt is supposed to be a place where programs that don't want to co-operate are granted ownership of one directory to install stuff in, which they can organize as they wish. It's often used as a way to install badly-packaged proprietary software or to give "foreign" package managers a place to put their packages. Brew wanting to take over /usr/local is kind of like a package manager wanting to take over the whole /opt. It's overstepping its bounds.

DominoTree 4y ago

FWIW, using the `--force-bottle` flag will force homebrew to install its existing pre-built packages into a non-standard path you've configured instead of compiling them from scratch, and I've never run into an issue with a package doing it that way.

ricardobeat 4y ago

> a package management system that will literally yell at you if you try to do something about "huh, maybe it's not great my executables are writeable by my account without requiring authorization first" I assume “asking for authorization” means sudo. That’s a lot more dangerous, since installers can then modify anything on your system, this is the reason homebrew is set up to avoid it.

DavideNL 4y ago
Note that you could just setup/run brew as another Admin useraccount (without using sudo.) So from your main non-Admin account you can then do `su - myadminuser` to then run `brew install vim`, etc.
- ricardobeat 4y ago
  Won't this alternative admin account also have access to the entire filesystem during installs?
  - DavideNL 4y ago
    The point is; First of all, the standard (non-admin) user can't directly write to/change brew files. So neither can all the apps you run. You'd first have to change to the admin user with `su - myadminuser`. An admin user does not equal the 'root' user, which has even more permissions. You still have to first `sudo -i` as the admin user, to become root (which is not needed for brew.)

rvieira 4y ago

I've always used brew, but sometime in the last few of years (Mojave?) I was plagued with these problems when installing different versions of Python simultaneously. Either brew broke Python installs, broke things like asdf, couldn't build Python from scratch, virtualenvs broke. Hair-pulling stuff. I decided to use MacPorts just for Python and switching Python versions worked perfectly. Eventually I migrated most of the brew stuff to MacPorts. I'm not saying one is superior to another, it's just that in my very personal experience and uses, I don't find anything in brew that MacPorts doesn't give me.

b3morales 4y ago
It's been a while since I've looked into it, but last I knew MacPorts was much more aggressive than brew about just not sharing dependencies between packages, to avoid this kind of thing. In effect, trading disk space against fragility.
NegativeLatency 4y ago
asdf has been nice for managing programming language versions
rcarmo 4y ago
I use brew with pyenv and never looked back.
chrisfinazzo 4y ago
Like rcarmo, I looked at pyenv as it shared (Read: copied wholesale for obvious reasons) many of the ideas in rbenv which has been excellent for dealing with different versions of Ruby. Either I just couldn't get used to it or the similarities are not as clear as they might appear to be at first glance because I eventually gave up and backed off Python entirely until miniconda was available via brew and BBEdit gained the ability to switch environments without jumping through hoops. That said, I am currently trying to remove Python from brew entirely and put everything into conda - for a few upgrades now, brew has complained loudly during upgrades that compiling from source isn't supported and may break things. I can run `brew uses $FORMULA` to find the things that depend on Python that brew knows about - is it generally safe to move these into conda's "base" environment? The main thing that I use conda for (The Standard Ebooks project) has an environment and version of Py all to itself.

zenlf 4y ago

I clicked on this and expected something really bad about brew. It turns out just the default setting doesn’t satisfy the writer’s use case. The energy and attitude of this article really sticks me as odd especially considering Brew is free to use and not some sort of default package manager that comes with your macOS. If you want to write a guide to do something, great. You contribute to the collective knowledge base, but there is absolutely no need having this combative attitude towards somebody are doing the same.

iepathos 4y ago
Yeah, I was surprised the author had an issue with using /opt since that's the expected location in *nix for the installation of add-on application software packages. Maybe he's running a multi-user machine and really wants brew in his home directory for that reason.
- nerdponx 4y ago
  If anything, Brew going in /opt makes a whole lot more sense than the old default of /usr/local. Supporting individual per-user installs in the home directory would be really nice of course, but I guess that's just not something they intend to support (it's offered on Linux on the "you are on your own, good luck" basis).
  - craigching 4y ago
    Agreed. When brew installed in /usr/local I ranted much like this post. I’m much happier with brew since the move to /opt.
nerdponx 4y ago
I think it's "cool" in some circle to hate on Homebrew. It's not my favorite piece of software (I prefer MacPorts), but it's improved a lot over the years and its existence does a lot of good for a hell of a lot of people.
Decker87 4y ago
It's what gets the clicks.

jxi 4y ago

Casks still need root to install apps into /Applications

racl101 4y ago

I've never hated a package manager more.

kdtsh 4y ago
Hate is such a strong feeling to have towards a package manager. I don’t see how a freely built, freely available tool that you don’t have to use could cause such negative feelings, but if you just don’t use it then you’ll get over it.
- racl101 4y ago
  Heh, yeah I get what you're saying. Sounds overtly dramatic. But let me explain: I don't use it personally. I prefer to use virtual machines or Docker for my own workstation. But I am in a position to have to troubleshoot other people's Macbooks with this package manager ... so yeah. I stand by what I said. I wouldn't mind if other people troubleshooted their own stations at work.
  - kdtsh 4y ago
    Fair enough, if a user is maintaining packages on their computer with Homebrew I feel like they should take some responsibility for that. Unless it’s a cask, they should figure it out themselves or you can only really provide your best efforts. If you use a third-party package manager you should learn to be comfortable and familiar with how it works, or at least with how packages are declared, so you can troubleshoot your own problems and if necessary raise issues on the project.

FullyFunctional 4y ago

I have mixed feelings about brew; it’s very convenient but the one time I reported a bug I instantly got banned and yelled at because of my wording. It was very one-sided as I wasn’t able to apologize or even explain due to the insta-ban. My one other interaction with brew community was similar; absolutely any critique is taken as a holy war. I’d really rather Apple made it unnecessary to plug this hole and render brew redundant. ADD: for the record my “offense” was saying “Are you for real?” when they screwed up and reverted back to an ancient version. I was shocked by that lack of QA but sure, I could have said it better. Still, cancel culture meant the end of that conversation.

TillE 4y ago
> for the record my “offense” was saying “Are you for real?” when they screwed up It's really not hard to just not be a jerk, even when someone else has made a mistake. Just be kind. Or at the very least, be calm and factual and nothing else. It makes everyone's lives a little better, including your own.
- FullyFunctional 4y ago
  Hindsight is so easy and I wanted to apologize, but wasn’t allowed. It was certainly taken as more offensive than I had intended and I realized that, but too late.
- userbinator 4y ago
  It says a lot that you perceive such a short and IMHO well-deserved expression of frustration as "being a jerk". If I was on the receiving end of that, I would only apologise as being the one at fault. That's what defuses the situation instead of aggravating it. It makes everyone's lives a little better, including your own. No it doesn't. This "forced positivity" is far worse in the long term.
  - acdha 4y ago
    Another way of thinking about it: Homebrew is a volunteer project which tons of people depend on for work but don't contribute to. If the volunteers get a ton of low-value comments from people who are talking like they have a support contract, blocking those people is a way of protecting the volunteers. I may not like it as the ideal outcome but I prefer that maintainers don't burn out, too.

password4321 4y ago

I quit using homebrew after the auto-update-everything kicked in as part of installing some new tiny utility. Both Apple and homebrew had transitioned away from supporting my OS recently... several working versions of software were uninstalled, then something failed to build, leaving behind a total disaster. I wouldn't even consider using it again without HOMEBREW_NO_AUTO_UPDATE=1. MacPorts has been good to me, it even has an ncdu1 package since Zig doesn't support legacy macOS either. Ask HN: Best Alternative to Homebrew in 2021? https://news.ycombinator.com/item?id=29079096 https://news.ycombinator.com/item?id=29079096

laserlight 4y ago
I wonder who thought the autoupdate is a good idea. It's absolutely crazy. Lots of things break down and some of them do silently, making it really difficult to find the problem when one discovers it days or weeks after the autoupdate.
- acdha 4y ago
  On a clean system it’s rare to have things break so if you’re an open source developer you prefer people use the current release of something rather than re-reporting bugs you fixed 3 years ago.
hparadiz 4y ago
Thank you for this little bit of sanity.
pgorczak 4y ago
Seconding this, I have lots of Python virtual environments with packages that link to brew libs. It’s a bummer coming back to an env after a while and then realizing auto update has removed linked files due to a minor version bump
rjzzleep 4y ago
I used gentoo prefix for a long time and it was a much much better citizen than homebrew(which isn't hard TBH). But gentoo has a terrible way of engaging the community. I tried to contribute but it was just cumbersome. So in the end back in the days I still had my own clang patches(basically before all the apple changes were upstreamed).

spaceywilly 4y ago

>homebrew (grudgingly?) supports being installed in a non-standard folder. They just don't suggest it to you up front. It's tucked away in the detailed installation page under "Alternative Installs" Oh good, another user of an open source project expecting the devs to support their special setup, while (presumably) not contributing anything back.

guimplen 4y ago
Your comment would be relevant if the guy written something to the devs. He has a sacred right to rant on his own page as he likes.
- spaceywilly 4y ago
  But his rant could’ve easily been a pull request in the Brew repo. Would’ve taken just as much (maybe even less) than what he did to come up with his own solution. Let’s say he added a —sandbox option to the home brew install script that did all this automatically. Now it benefits everyone using homebrew. The whole tone of the article is pretty hostile and childish, which is a toxic attitude in my opinion. Better to be cooperative and help out the community.

pxc 4y ago

What the OP describes is how I use Homebrew on macOS: non-standard prefix, not on the PATH. The other thing I do is use it exclusively for 'Casks' (pre-built .app bundles distributed as .dmg or .pkg). If you do this, you can use any combination of Nix, pkgsrc, and MacPorts for your traditional Unix-y package needs.

jordemort 4y ago

I used to be cranky about it taking over /usr/local but since I upgraded to an M1 I have no problem with it hanging out in /opt. I don’t understand why the path switched when the architecture did but I’m happy about the change.

frizlab 4y ago
I think it’s easier to maintain the bottles for two different architectures at two different paths, and the /usr/local path take over was a recurrent complaint, so the devs took advantage of the new arch to change the path.
- Hackbraten 4y ago
  Ex-Homebrew maintainer here. You’re correct. I couldn’t have explained it better.
fijiaarone 4y ago
Brew moving to /opt was nice on M1 but nothing being able to compile on M1 is a bit inconvenient. But that’s not brew’s fault.
- mdaniel 4y ago
  I mean, that can't possibly be true, right? The bottles don't appear out of nowhere. So "brew install --build-from-source bash" dies for you?
- jordemort 4y ago
  Not sure if your issue is brew-specific, I've compiled plenty of stuff since getting my M1
acdha 4y ago
No legacy systems meant they didn’t have to worry about whining when they switched since everyone was by definition using a new install.

orliesaurus 4y ago

I use brew all the time, and I found the title of this article was super-negative for no reason?

OrderlyTiamat 4y ago

Is there a guide like this for anaconda? I'd really prefer to have it "shoved into its own little corner " without it touching my bashrc and the like. I'm currently isntalling it with nix-env, which is great, but nix is a tad overkill, and if/when I'm done experimenting with nix, I'd like to have a way to use conda for projects that require it, but have it otherwise leave me the hell alone.

OrderlyTiamat 4y ago

skybrian 4y ago

I have less of a problem with Brew and more with installation procedures that require Brew. For example, instructions for using the Raspberry Pi Pico C SDK typically start with "brew install cmake". CMake itself supports Mac OS 10.10 or later. Brew requires 10.15, so if you depend on CMake via Brew then you're cutting off people with older systems. Furthermore, trying to install via brew means you'll pull in other unnecessary dependencies. It tried to install Python for some reason but failed. (Python itself supports Mac 10.11 or later, but Brew apparently tries some other way of doing it.) Yes, I should buy a newer machine, but many other programming tools work fine.

alexjurkiewicz 4y ago
10.10 has been eol for five years without security updates. How long should downstream tools support an eol OS?
- skybrian 4y ago
  I'd guess CMake supports it just because they haven't seen a reason to require a newer version yet. Command line tools are like that. (The Go SDK requires 10.13.) That's the difference between what people can do for individual tools versus an entire ecosystem like Brew that's trying to do everything.

FullyFunctional 4y ago

My worry with brew and literally any software installed from "random" sources is that I don't want to trust it, but it runs with all my credentials and can do just about anything on my behalf. When using, say, macOS or Ubuntu, I have made the deliberate decision to trust the vendor to not be subversive, but as soon as you bring in outside sources you expose yourself. This isn't an academic concern, Log4J and the ongoing phishing attacks on PyPI are good reminders. Apple at least seems to be taking it seriously and has started requiring explicit authorization to access various locations (like Photos), but treats the shell as single security domain, so it's (AFAICT) a global setting for brew installed binaries. For Linux I don't know of anything similar. Obviously there are many things one can do but it needs to be the default and it needs to be not so inconvenient that people just turns it off (hello Microsoft Vista's UAC). What are the solutions here?

kdtsh 4y ago
SELinux or AppArmor provide MAC if that’s what you’re looking for.

deleted 4y ago

[deleted]

watersb 4y ago

Also: tools that insist on crapping on my shell environment, `.{bash,zsh}rc` or `.profile` -- I like SourceTree [0] (to unfairly call out just one example), and while I'm aware of alternatives, it's cross platform, available to me without $$ payment ... but it is convinced that it cannot work without adding a block of code to my shell config. @OrderlyTiamat mentions Python world Anaconda https://news.ycombinator.com/item?id=32706193 https://news.ycombinator.com/item?id=32706193 @acdna acknowledges the more general idea of namespace pollution but if I'm reading it right, doesn't think it's a security issue particular to HomeBrew https://news.ycombinator.com/item?id=32707109 https://news.ycombinator.com/item?id=32707109 I can agree that taking over a namespace in the $PATH adds cognitive load to security vigilance, but I can accept that this is standard POSIX reality... But I don't like it when tools add to my $PATH - and then edit my config files in addition to that. I happen to like the UNIX way of filesystem structure for configuration. Re-writing my configuration on program launch takes away that very UNIX strength of composable tools and text files. [0] SourceTree: a nice Git GUI with `.ssh` integration -- https://www.sourcetreeapp.com https://www.sourcetreeapp.com (the ssh keychain is still a problem for me but I've only been trying to fix it for 20 years, and yes I try the nice keychain CLI tool from drobbins and macOS keychain integration and stuffs)

vario 4y ago

there is no alternative better than Brew--and its latest version has very good defaults in place: no need for sudo, everything tucked in a little safe corner, auto-runs update before a new install, and helpful error messages. I don't see why we should be so nitpicking over something that serves us so well.

ElCapitanMarkla 4y ago

I really don’t get all the hate I encounter around brew. I’ve been using it for ~10 years and largely without issue, I certainly wouldn’t say I’ve had less issues with other package managers on Linux etc. That auto update feature they’re flicked on is a pain in the ass though.