Brew Is a Bad Neighbor
gist.github.com
gist.github.com
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.
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.
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:
https://github.com/Homebrew/homebrew-core/issues?q=author%3A... https://github.com/Homebrew/brew/issues?q=author%3Apudquick
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.
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.
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.
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.
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.)
> 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”.
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.
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.
> I agree that this particular security mitigation is probably of limited usefulness in this scenario
> If you want me to agree that it would be better if the tone of the memo were more forgiving, I do agree
Not trying to be condescending by quoting myself here, but we're basically already at an agreement; The linked post has some issues.
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?
That seems like an appropriate title would be “TIL: how to install Homebrew in a custom path” rather than the hyperbolic one he picked.
And you don’t think the article ticks that box?
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.
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.
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?
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.
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.
It was certainly taken as more offensive than I had intended and I realized that, but too late.
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.
Blocking only encourages further polarisation and animosity. There is nothing to "protect" but their own fragile egos.
In other words, they basically have the same attitude as Apple itself.
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.
One could just as well argue that GP commenter screwed up and made a mistake, no need to instantly ban them with no recourse to even apologise for it.
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.
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.
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.
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.
This rule works surprisingly well.
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.
Now I am surprised that I don't have any general rule for C and Java.
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
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.
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.
Regarding the permission problem: have never had any issue, but that's probably because I don't mix multiple users and developer tools.
I don’t even use Macports, but that’s just plain unfair.
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?
I was making an observation based on the fact that PowerPC Macs were discontinued in 2006 and homebrew was created in 2016.
So Macports (or other) could’ve changed things in the last 16yrs, which have been quite transformational for computers and software.
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'm very confused as to what threat model leads to this concern on an unsandboxed (predominantly) single-user desktop OS such as macOS.
I love that the things people will say about macOS include both 'certified Unix' and 'single-user OS'.
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.
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.
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.
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.
> 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!
FTFY
Now you're obviously trolling.
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.
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.
macOS and Windows feel like toys in comparison to Linux which is an actual productivity tool.
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.
Would be curious to know what's the point as this never happened to me. In almost 25 years of Linux usage.
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.
Something like that could probably only happen on a broken OS, I guess.
Pop!OS? Isn't that a FrankenDebian in the first place, so all bets are off anyway?
https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_Frank...
> The second most common way is installing random packages from the internet […]
How any package manager on any OS could prevent breakage when the user tries hard to break the system at will?
Now I'm a little bit confused.
I wish people understood this, but sadly they seem to be more and more common as primary modes for software distribution.
And have those package managers manage to work without sudo in 2022?
But why is that a requirement? Homebrew doesn't work without root; it only pretends to.
How many of those are "built in into OS unlike the other OSes"?
> But why is that a requirement? Homebrew doesn't work without root; it only pretends to.
Can't remember when I last needed to run sudo with brew. Whereas I've yet to see a Linux distribution able to install anything per user.
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.
> 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".
The best package manager for macOS is Docker with an Alpine container. Not ruby scripts with git as a backend and questionable permissions.
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.
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.
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?
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.
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.
That's the difference between what people can do for individual tools versus an entire ecosystem like Brew that's trying to do everything.
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
@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.
[0] SourceTree: a nice Git GUI with `.ssh` integration -- 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)
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.
So from your main non-Admin account you can then do `su - myadminuser` to then run `brew install vim`, etc.
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.)
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.
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.
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.
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..
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?
That auto update feature they’re flicked on is a pain in the ass though.
But that’s not brew’s fault.
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.
If you do this, you can use any combination of Nix, pkgsrc, and MacPorts for your traditional Unix-y package needs.
I don't see why we should be so nitpicking over something that serves us so well.
Oh good, another user of an open source project expecting the devs to support their special setup, while (presumably) not contributing anything back.
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.