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.
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.
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).
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.
Serious question: Why do Hacker News commenters constantly "tone police" articles that are not written for Hacker News?
I don't know what criticisms of an article's tone contribute to the collective knowledge base.
If an article author did not show the respect toward something that you think something deserves, you're entitled to your personal feelings, but are we here just to say "I like this" or "I don't like that"? It always seems like HN revels in diversions, irrelevancies, and nitpicking, which typically distracts from the main points of an article. As proof of this, the OP is currently the top voted comment for the article, and a similar comment is the 2nd most upvoted.
There are two trends at work here: the most generic is the tendency for clickbait to drown out more substantial work. In this case, the provocative title isn't supported by the contents so it'll leave most readers disappointed.
The second is that there are a lot of HN users who are active open source developers and that community has grown increasingly tired of whining by people who feel entitled to have their opinions shape projects without doing any work to help those projects. Starting with “Brew Is a Bad Neighbor”, he basically craps all over a huge amount of work which hundreds of developers have given him for free and can't even acknowledge things like them having given him the ability to do exactly what he wants – note the little snide parts like “(grudgingly?)” or the way the information presented in the default documentation is described as some kind of secret reveal.
Note that he has _never_ attempted to contribute to either project:
It's perfectly fine not to contribute to projects you use, or to have strong opinions about how to architect things, but it'll definitely rub people the wrong way to not to contribute but have a “Why Wasn't I Consulted!?!” post.
It's also common for people here to question things because they don't agree that a particular post is worth the community's time. Many of the comments here seem like meta-discussion to the submitter.
> In this case, the provocative title isn't supported by the contents so it'll leave most readers disappointed.
One problem is with Hacker News itself: it makes no space for context other than an article title.
Whereas the gist was originally posted by the author in a tweet that said "Wrote a guide on how I keep homebrew in its place" and also had a screenshot of some of the article contents. And the people who would see it were those who followed the author (a lot of Mac admins).
HN submitters are not supposed to editorialize an article title. But, maybe HN should make room for an article summary that does editorialize!
Google search results for example have a little summary too, not just a link and a title. So you can make some kind of judgment about the content before clicking.
> it'll definitely rub people the wrong way to not to contribute but have a “Why Wasn't I Consulted!?!” post
How is this one such a post?
To be clear, though, there are some people who only use homebrew because some project requires it, and not because they want to use homebrew. So contributing to homebrew is the last thing they'd want to do, even though they use it sometimes, reluctantly.
It's fairly common for the cheapest thing to become the most popular thing, even if it turns out to be one of the worst things possible. Cheap and free too often crowd out better possibilities. With that in mind, I don't take "they provide it for free" to make something immune from criticism. My unpopular opinion is that there's actually too much open source in the world, and software developers are undermining themselves in the race to the bottom.
> Many of the comments here seem like meta-discussion to the submitter.
Well, I think it's unfair to take that out on the article author, who did not submit it to HN.
For whatever reason, HN does not allow downvoting of articles, only upvoting. I would take that up with dang. :-)
On the other hand, the article does contain useful instructions that are worthwhile for some people.
There isn't really anything else to respond to here. This person doesn't like homebrew but doesn't really say why, so we can't discuss their reasons. The rest of the post is instructions to solve a problem most people don't have, so there isn't really anything to say about those. The end result is that you're left with nothing but tone-policing and people who just read the title and decided to post their unrelated complaints. The tone policing gets upvoted above the latter because it's at least vaguely about the thing we're hypothetically commenting on.
The real question is why it got upvoted given that seemingly no one read it and has anything to say about the content of the post. I'd guess it's the people who just wanted a place to air their unrelated grievances.
> The real question is why it got upvoted given that seemingly no one read it and has anything to say about the content of the post. I'd guess it's the people who just wanted a place to air their unrelated grievances.
It may be "a problem most people don't have", as you say, but it's still a problem that some people have, and homebrew is used by a lot of people, so another possibility is that people upvoted the article because they found it useful.
It's not written as if Homebrew developers are forcing you to use it. It's written from the perspective of someone who doesn't really want to use Homebrew but still does so as a result of some decision calculus but finds it frustrating to use. If you find the tone to be too aggressive or unfriendly, that's fine. But also, in the same token, I don't think it's fair to invoke the "you don't have to use it" argument for fairly reasonable frustration. It's also not obligatory that anyone take someone's rant personally, after all.
That’s a very charitable reason: this post is long on unsupported allegations starting with the title and boils down to the author not understanding security as well as he thinks and claiming it’s Homebrew’s fault that something unsupported requires more work.
Well, I find it pretty frustrating when software on my machine breaks due to namespace pollution that happened automatically and without warning. Some MSys distributions do similar things on Windows, and I find it no less agitating (To be fair, at least Homebrew doesn't generally override e.g. system utilities with GNU utilities, and is somewhat careful about it, but it nonetheless does generally require itself to be on $PATH iirc. Still, my build processes regularly pick up things like Homebrew OpenSSL completely unintentionally...)
Ignoring the security issue for a moment, though, I think it is genuinely quite irritating that Homebrew doesn't support installing in a more self-contained manner. I'm not saying Homebrew developers did anything wrong to me personally or that they are obligated to work on the problem, but the other edge of that sword is that I don't have to like it either. It can be done, as shown, but it is pretty intentional about not supporting this workflow. I think that's a bummer.
(P.S.: I honestly didn't really grasp exactly what they were complaining about, but if they are trying to enforce a setup where the only binaries in the default shell $PATH are in directories that are not world-writable, that really does seem like a totally valid security mitigation.)
I mean, yes, namespace pollution is a problem but Homebrew goes to a fair amount of effort to avoid that. I have to add things like OpenSSL, etc. to my direnv for projects where I want to use those instead of the system versions and they support using /opt/homebrew on older systems, too, for people who don't mind skipping bottle builds.
> if they are trying to enforce a setup where the only binaries in the default shell $PATH are in directories that are not world-writable, that really does seem like a totally valid security mitigation.
Think about what threats you're concerned about. Homebrew installs are writable only by the user who installed them and members of the admin group. If you're not on a system with other users, this doesn't matter: someone who can run code or drop files into arbitrary locations as you can already do whatever they want (e.g. maybe you lock down /usr/local but do they even care as they drop something into your .profile or LaunchDaemons?). That's why Apple has worked on the various sandboxing methods because this model is too brittle.
If you are on a multiuser system, this could be a way to move sideways but it comes down to the question of how likely it is that an attacker would compromise the admin user who installed Homebrew without getting the ability to use their administrative privileges. That's certainly possible but it seems relatively uncommon and that's part of why I think it's a huge stretch to go from “there's an obscure edge case I want to hit” to “These people who've given me thousands of hours of their work for free are bad neighbors”.
I agree that this particular security mitigation is probably of limited usefulness in this scenario, because it's on macOS, and because the $PATH is likely only modified for the current user. (Maybe it was actually a bigger issue when Homebrew used /usr/local instead?)
However, I will hold that this mitigation in general still can be useful. After all, not every security issue is actually full remote code execution. There's plenty of security issues that allow you to write files somewhere; for example, path traversal bugs in PHP scripts, archivers, Git, etc. If being able to write files somewhere allows you to escalate privileges to another higher privilege user transparently without user input by overriding something on the $PATH of a cronjob, that really is an issue. Mitigating this risk on its own obviously doesn't net you a secure system, but as part of a security moat of sorts, it is certainly not useless.
> That's certainly possible but it seems relatively uncommon and that's part of why I think it's a huge stretch to go from “there's an obscure edge case I want to hit” to “These people who've given me thousands of hours of their work for free are bad neighbors”.
I guess I didn't take the phrasing "bad neighbors" to be all that hostile. It's certainly a curt way to complain about namespace pollution, but honestly, it does seem like an apt description of namespace pollution. If you want me to agree that it would be better if the tone of the memo were more forgiving, I do agree; but also, it does just seem like a frustrated rant, and it doesn't seem like it is aimed to personally attack anyone. I think that as an open source dev, while obviously everyone is human and has their limits, it's probably best to try not to take it personally as much as you can stomach it.
re: OpenSSL. I honestly think this might be the fault of Homebrew pkg-config being in my $PATH, or maybe a CMake find script just goes out of its way and it's not Homebrew's fault at all. Not sure. But, I did actually run into it at one point, and now I am very paranoid about ldd'ing macOS binaries I produce when the machine has Homebrew installed. Whoever's fault this is ultimately doesn't matter too much, but it sure is frustrating.
> Mitigating this risk on its own obviously doesn't net you a secure system, but as part of a security moat of sorts, it is certainly not useless.
No, that's why people keep talking about multi-user systems. On a developer workstation it's almost pointless. If people were running Homebrew on servers and it defaulted to allowing other users to write to its directory, he'd have more of a point but since the former isn't common and the latter isn't the case, it's not really helping anyone to present this in such bold terms.
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.
Pointing out the flaws in open source software is totally fair, especially when the software is popular enough to have a gravitational pull on the rest of the ecosystem.
Of course, you need to be mindful not to be a jerk to the developers and maintainers, but that is different from criticizing the software.
If criticism of open source software was “problematic entitlement”, then I guess we’d have to swallow our tongues when Linux, Android, Chromium, Firefox, etc. make poor decisions. After all, they’ve helped billions of users, so who are we to question them?
This article is aggressive but does it really point out a flaw? It alleged a few problems but didn’t substantiate anything (doing so would likely have helped the author learn why the security point is mostly theater) and the bulk of it was describing how it was more work to use an unsupported configuration but still relatively easy because the Homebrew authors documented how to do so.
That seems like an appropriate title would be “TIL: how to install Homebrew in a custom path” rather than the hyperbolic one he picked.
> 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.
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.
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.
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.
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.
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
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).
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.
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.
In other words, you're saying those volunteers are just in it for their own gratification, which explains very well the attitude they treat everyone else with.
Blocking only encourages further polarisation and animosity. There is nothing to "protect" but their own fragile egos.
No, I’m saying that being mean to volunteers is never a good move. If you want to have influence on a project, roll up your sleeves and contribute - and still be polite, nobody is getting paid to deal with rude people.
Once again, I do not think that is "rude" AT ALL! Their fucked-up sense of perception is at fault here. I really wonder how such people can live their lives with such thin skin.
It's not just you; I've only had to touch brew a rare few times (because I normally don't work on Apple stuff unless I absolutely need to for some reason), and I also quickly noticed how the "discussions" on issues are absolutely one-sided most of the time. They are extremely quick to take offense.
In other words, they basically have the same attitude as Apple itself.
> my “offense” was saying “Are you for real?” when they screwed up
Volunteers banning someone with an asshole tendency is not cancel culture. Just don’t be like that.
People screw up and make mistakes, no need to insult them for it. The proper way to react is to thank them for fixing it.
I find it interesting that you see this as an "asshole tendancy".
I don't believe most people in my country would take this as an insult. There are many people from many countries (and subcultures within those countries) with differing degrees of what they will take offense from. From my perspective, the developer perceived a slight incorrectly for sure.
Personally I think it's perfectly fine. Just a few people can take a lot of your mental energy and make you less interested in your own project. Not being a company you don't have to deal with this and somehow there seem to be power law distribution like everywhere else - I mean if you provide support, a few people will use as much of your time as the whole bottom half of them.
So even if you would have 90% chance of false positive it may be worth it.
At the same time, if you treat them charitable, ignore emotions and do your best with such people/comments, they may also turn out to be great contributors and valuable feedback. Just the fact that somebody takes his time, his most valuable resource, to provide any kind of feedback is something. There are popular projects with known bugs which take a lot of time to reach developers because everybody is busy with their own stuff and doesn't have time to report stuff which others may just as well report. Plus, such person is more likely to share their experience with others which may discourage or encourage some potential contributors like it is happening right now.
It is amazing how much PR can a single person do over the years when she has really strong opinion about something.
I find the comments responding to you, defending their behaviour, thoroughly unsettling. But neither is the behaviour of the team, nor these comments, surprising. It's a slice of the culture that pervades the user base and development team and has been so for several years.
It's not cancel culture. It's breaking the rules and someone upholding rules.
"I wanted to apologize"
I'm pretty sure if you really wanted to apologize, you could have. Being banned in one location doesn't preclude you from reaching out in other ways.
Finally, you say that was your only offense, but I need proof that this was the ONLY thing you did that was offensive, or that was just the straw that broke the camels back.
Considering you equated "upholding rules" as "cancel culture" you aren't really unbiased.
This has nothing to do with cancel culture, you're just a moron. An open source maintainer gets to set their boundaries with you however they want. If they want to instantly ban you for being an ass that's on them.
If anything, what you are doing RIGHT NOW is inciting cancel culture. You want the culture of Mac users to know you were slighted by a brew maintainer, and that they should be punished in some way for that interaction.
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.
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.
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.
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.
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.
I might try MacPorts again next time I do a fresh OS install.
Last time I used it was back in the mid-late 2000s, before my technical capabilities were decent (could only barely write code and was basically clueless about the GNU toolchain and the like) and at that point, MacPorts packages were frequently broken and would sometimes remain that way for long stretches of time, with the only fixes being manually applied local patches (if they existed at all). It was very frustrating, and so when Homebrew came around and packages generally "just worked" I was an instant convert. I wouldn't be surprised if a lot of other people who were newbies during that time span have similar stories.
> MacPorts packages were frequently broken and would sometimes remain that way for long stretches of time, with the only fixes being manually applied local patches (if they existed at all)
That was my experience as well a couple of years ago, with some quite painful OS transitions. Still, I’ve been using it for I think a decade now, and I cannot remember any problem in the last 4 years or so. It does not have everything as Homebrew is the cool kid and cool devs do not care about anything else, but it is solid. And last time I looked it had a much more sensible way of working than brew and a better security model, even if it leads to some duplication in the installed packages.
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.
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.
I described the origin of the current situation. Considering you are not a consumer of MacPorts there is no point of reference for you, so you would not know how the current inadequacies came to be.
Trying to judge the fairness of a technical aspect of a piece of software as a non-user seems rather pointless, don't you agree?
While some issues have been solved, a lot of them simply migrated from the core ports system to the ports themselves.
The difference in goals and tooling between the dpkg (Fink for macOS), ports (MacPorts for macOS) and brew systems seems to make all the remaining volunteers flow towards brew as the work required to fix ports is either harder, or getting the fix into MacPorts is harder. And sine Fink is dead, there is no dpkg-way to try out anymore.
I think RPM was never tried, and Nix is still an option but since you'll end up learning functional programming to use it, it won't get the hold the Nix-enjoyers seem to enjoy. Maybe Guix can inspire something, but I think the bar to entry with brew is really hard to beat.
The end result is broken and/or outdated ports, and even with the fixes post-macOS Forge the lack of content and port-fixes just makes it a non-starter when things like brew exist.
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
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.
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.
I wish there was one universal package manager which provides binaries for all platforms, stable/beta/nightly, unverified and verified
No more “apt get”, “pacman -S”, “brew install”, etc. you just run “pkg add <package>” and it will a) actually have the package and b) download or build it whether you’re on debian, arch, macos, openBSD, etc.
You can configure to use the stable or nightly packages, you can add custom package repos including an AUR-equivalent “unverified” repo (and remove the default “verified but not securely audited” repo), you can configure to build everything manually if you want or only download prebuilt binaries, or download source code, or documentation. And you
can do this globally, for users, for groups of packages, or for individual packages. You can patch local packages, you can define a buildscript and publish your own packages from their git repos, etc. You can even use a stable version of one package and force it to have nightly dependencies (or vice versa), probably not a good idea but you do you.
Honestly it sounds so simple but it isn’t implemented. Instead we have Debian for stable packages, Arch for nightly packages and AUR, macOS has homebrew with all its criticisms or MacPorts, and BSD has 3 different package managers all with their own flaws. And languages have their own package managers, which is fine (bc you’re not going to use one language’s package manager for another) but it would be nice to get that unified as well and have superior dependency resolution, workspaces, etc. for every language.
There are cross-platform package managers: pkgsrc and nix for example, and I believe HomeBrew runs on Linux too.
It's not that simple though as certain choices are fundamentally incompatible. In Debian packagers are expected to take "ownership" of the package, backport fixes, apply patches or fixes to integrate better with the Debian system, etc.
On Arch Linux, it will ship the latest stable version from upstream with as little modifications as possible.
You can go with one approach or you can go with the other, but you can't really do both at the same time.
Then there's the design of the tooling itself: apt behaves fundamentally different from pacman.
Some things can probably be unified here and there, but I don't think it's quite that simple.
The tooling side isn't the tricky part, it's the insane amount of work that is required to create and maintain each package. You need massive community buy in. Because of this, unfortunately, the best package managers aren't the most sound, the best are the most popular.
Arch doesn't use nightly packages. They use stable and Debian often use several releases behind. Your statement is like saying that using the latest official stable version of Nginx is the same as nightly and doesn't instill a lot of confidence in whatever point you're trying to make.
Except for when they don't. Which is more often than it should be.
If I had a dime for every hour of my life wasted by distro package managers (or really any package manager) breaking when I try to do some basic operation, I'd be a very rich person.
It's been a long while since I've used Linux for anything but servers, but I have to agree. Not just with package management but pretty much anything in Linux outside the server domain. I used to waste so much time dealing with conflicts between packages, but also on weird bugs with graphics and audio, xorg.conf, etc., just to get things to work as expected. This comment kinda just turned into a rant about Linux in general. Unless things have changed, I wouldn't recommend Linux as a desktop to anyone but masochists. It's definitely a good thing that Linux distros have package management built-in, but that doesn't mean there aren't significant drawbacks to the way the Linux community approaches it. In contrast, I rarely have issues when I run `brew install`. My memories of Aptitude aren't particularly fond.
Honest question: Why are you talking about something you haven't seen for more than at least 20 years?
Linux is the desktop with the least amount of WTFs. With a big margin!
All other OSes break with every update.
Even the perpetual "beta"-system Debian Testing is much more robust in day to day use than things like macOS or Windows (and that holds even while installing whatever daily Debian updates come along without thinking)..
On a (semi-stable) Linux (like Testing) there are never "conflicts between packages", btw. This can only happen if you make a mess and mix up different distros…
Please don't spread FUD in the future if you don't know what you're talking about. Thanks.
Where did I say 20 years? The last time I was using Linux (Debian mostly, Ubuntu, Mint, Crunch and) full time was back in 2016. Occasionally I've had to interact with them and their respective DEs over the years since, but I've been using macOS full time to this day. So 20 years? Not really, actually. More like 6 or 7.
> Even the perpetual "beta"-system Debian Testing is much more robust in day to day use than things like macOS or Windows (and that holds even while installing whatever daily Debian updates come along without thinking)..
I don't care how "robust" Linux is. Can a distro do everything I want without some caveat like horizontal tearing, weird audio incompatibilities, weird graphics driver issues, booting to black after updates, difficulty reconciling managed packages, files mysteriously being deleted from common file systems, or basic features disappearing from foundational apps like the file manager? If such a distro exists, I'd like to see it, because I've never installed any variety of Linux that didn't have annoyances not present on commercial operating systems. And yes, that includes any version of Debian.
Sorry Linux desktops, time is up. I spent ~13 years trying to love you, but you always have baggage. Maybe you don't anymore (I highly doubt that), but it's too late. And I'm not an outlier; your countless ex boyfriends and girlfriends agree with me.
> On a (semi-stable) Linux (like Testing) there are never "conflicts between packages", btw. This can only happen if you make a mess and mix up different distros…
Yeah right... no one ever has to install a version of software that's newer than what's in the distros respective repos. Those people all go through the trouble to guess what dependencies some source code relies and compiles everything by hand just to avoid pissing off Aptitude. /s
The real world doesn't work like that. Having package management be locked to the repo for the particular distro version is great for Linux as a server. It sucks ass if you're an everyday person just trying to do things other than fiddle with their OS. Ideally, the user should be hardly aware of their OS.
Sure, there's also this "Snaps" thing now, which I don't have experience with, but apparently there's something about it that pisses off a large amount of the Linux crowd.
And are you telling me you've never done anything custom to your Linux installations? Because that's one of the key features these distros sell themselves on. You can make Linux "your own." That sounds great, but what that means is even so much as changing which file manager you use can lead to disaster when you perform an update, even after doing all the allegedly right things.
Regardless, the way that distros manage packages can only serve to get in the way of users who aren't OS nerds. Any gain in stability comes at the potential cost of time wasted which does not exist nearly to the same extent on commercial operating systems.
The Linux crowd reminds me a lot of the amateur radio crowd. Just as Linux people say that their distros are now very stable and easy to use, the Hams think that it's worth the time of casually interested people to get a fully featured Ham radio setup with all the bells and whistles and to take the "easy" FCC license exam. Anyone who thinks radio is cool but isn't interested in studying and spending lots of time with electronics in their basement "doesn't know what they are talking about." In reality, a GMRS radio is probably better for most people in almost every case, just as most people should avoid Linux and use macOS or Windows instead. Linux DEs will never be popular with non-nerds unless their community stops acting like Hams, but that probably won't happen because Linux had been like Ham since I started using it. The community was saying exactly what you are saying today back in 2005.
> Please don't spread FUD in the future if you don't know what you're talking about.
That is a terrific piece of advice that anyone making an argument should take.
I've never had a Windows install break because of a dodgy update. Not saying it doesn't happen but its never happened to me, whereas when it has happened, its always been some Linux distro. Doesn't matter which because I've seen it happen on all the major ones (Ubuntu, Fedora, etc..)
In fact I have a Linux VM right now, pegging the host's CPU to 100% because of a broken update.
Honestly you should probably take your own advice re: not know what you're talking about.
>>Linux is the desktop with the most amount of WTFs. With a big margin!
xorg.conf doesn't even exist anymore on most systems. The others have been improved quite a bit since "a long while" ago.
That doesn't mean you have to try it again to update your opinions, if you have something else you're happy with now, but it does mean you should consider not spreading nonsense about things you haven't used.
I can't even remember the last time I had to look at an xorg configuration file. I think it must have been a decade; maybe longer.
Back in the XFree86 and early Xorg days it could be a pain though, but that was a long time ago. "X -configure" asking you about monitor refresh rates that I never knew the answer to ... ah, old times.
How did you calibrate this? I've certainly had no more (far less) trouble with apt-get over the past decade than I have with any commercial OS package installation. What standard is Linux package management being measured against that currently exists? Package management is a dream on Linux compared to wrangling Windows software.
All of the common Linux package managers make it really easy to accidentally shoot yourself in the foot in my experience. apt and yum/dnf are the most frequent offenders in my case, but I've managed to do it with pacman and portage too.
Most commonly, dependency conflicts. Probably the most well known example of this was Linus of the Linus Tech Tips YouTube channel accidentally rendering his Pop!OS install unusable by installing Steam.
The second most common way is installing random packages from the internet in attempt to get something working. This is one I ran into years ago trying to get audio working under Fedora on some random laptop.
> How many of those are "built in into OS unlike the other OSes"?
There are distros where each of the three is shipped with the OS and used to distribute applications that are installed by default, but Flatpak isn't a 'system package manager' in that it doesn't supply things like the libc that lives in /usr/lib or equivalent.
All three are also portable and hermetic enough, though, that they can safely be used on other operating systems without interfering with the base system.
> Whereas I've yet to see a Linux distribution able to install anything per user.
This is the norm on NixOS and GuixSD, the distros based on the Nix and Guix package managers, respectively. That kind of thing is still fairly marginal in the overall Linux landscape. It's also feasible with container-based package managers, which are growing in adoption, Flatpak chief among them.
Both NixOS and GuixSD have their own issues and can present special challenges to users, but the per-user package management functionality works well and is cool to see in action. They're definitely worth playing with in VMs if you haven't used them.
---------
Homebrew has been useful to many people for a long time, and it absolutely excels in UX. But the fundamentals are lacking and it's hard for third-party package managers to cope with Apple's changes on major macOS releases. There are definitely things that could improve for developers with a first-party offering. I get the defensiveness and I understand that Homebrew has strengths, but imo the standard critique along the lines of the OP is essentially correct.
> There are distros where each of the three is shipped with the OS
> All three are also portable and hermetic enough, though, that they can safely be used on other operating systems
The original statement was: "If you use an OS that doesn't do package management, maybe. Linux distros work just fine."
So, some distros.
> That kind of thing [installing without requiring sudo] is still fairly marginal in the overall Linux landscape.
Indeed.
> Both NixOS and GuixSD have their own issues and can present special challenges to users
Indeed.
> Homebrew has been useful to many people for a long time, and it absolutely excels in UX. But the fundamentals are lacking
Key being: it has been both useful, and it excels in UX. "Lacking in fundamentals" is important to a vanishingly small number of people who care about a random set of preferences they define as "fundamentals" (and probably don't even agree on this set).
> I get the defensiveness and I understand that Homebrew has strengths, but imo the standard critique along the lines of the OP is essentially correct.
There's no defensiveness around "you claim X, but if you dig not even that deep you find that your claims are misleading at best".
Rather than trying to force macOS to support package management, developers should be containerizing their environments where possible with docker/podman.
The best package manager for macOS is Docker with an Alpine container. Not ruby scripts with git as a backend and questionable permissions.
Does that work well for libraries that you use during software development? Or do you develop inside the container? What if you use two libraries and each has to live in its own container?
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.
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.
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.
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?
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.
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
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.
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.
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.
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.
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.
@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
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.
(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)
> 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.
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.)
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
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.
It doesn't sound to me like you were using brew as brew was intended to be used, if you are able to replace it with asdf. Asdf is extensible, but it doesn't have any kind of way to replace casks, or system package management. It is fine for managing js/ruby/etc environments, but that's it.
You missed the part where I said I switched to nix.
I don't care about casks or system package management. My use-case requires specific versions of tools, maybe GNU coreutils, and limped along with glibc or openssl, and that's about it. What asdf did not provide, Docker containers did. Until nix.
asdf is an awesome tool, but isn't it isn't a replacement for Homebrew. It is in the sense of installing and managing versions of programming languages, but Homebrew is more than that. You can't run `asdf install vs-code`, for example, unless you overload its functionality with a custom plugin.
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.
A recent tooling announcement <https://news.ycombinator.com/item?id=32600821> that uses nix under the hood finally got me to look further into it and while I know this isn't exactly what you asked, looking at their uninstall instructions <https://nixos.org/manual/nix/stable/installation/installing-...> leads me to believe ... it's probably not a great fit. I recognize that I'm probably more skeptical than most about "curl into bash" but if one needs to run that many sudo commands plus whatever "dscl" does in order to change your mind, that tool is not for me
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!
/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.
> 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..
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.
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).
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
>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.
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.
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.