Homebrew 3.0(brew.sh)
brew.sh
Homebrew 3.0
https://brew.sh/2021/02/05/homebrew-3.0.0/
515 comments
It reminds me about this answer from Homebrew's creator, Max Howell, on Quora[1]:
> I wrote a simple package manager. Anyone could write one. And in fact mine is pretty bad. It doesn't do dependency management properly. It doesn’t handle edge case behavior well. It isn’t well tested. It’s shit frankly. > Is it any surprise I couldn’t answer their heavily computer-science questions well? > On the other hand, my software was insanely successful. Why is that? Well the answer is not in the realm of computer science. I have always had a user-experience focus to my software. Homebrew cares about the user.
Yes, Homebrew's approach on package management is a bad smell to me. It gets broken by every other major OS update, it messes up your Python PATH for no good reason, it forces a lot of opinionated decisions on users if the maintainers think it benefits the majority(and ignores voice from minority)... But Homwbrew still wins because users really like it. It is that simple. With its popularity and the strong community, it will continue to be the top choice for most of the mac users. Max Howell may not be a rock star programmer in my mind, but I have no doubt that he could've been a very successful product manager.
Personally I don't plan to switch from macports to homebrew any time soon, but I stopped grumbling about how bad it is years ago.
1. https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
> I wrote a simple package manager. Anyone could write one. And in fact mine is pretty bad. It doesn't do dependency management properly. It doesn’t handle edge case behavior well. It isn’t well tested. It’s shit frankly. > Is it any surprise I couldn’t answer their heavily computer-science questions well? > On the other hand, my software was insanely successful. Why is that? Well the answer is not in the realm of computer science. I have always had a user-experience focus to my software. Homebrew cares about the user.
Yes, Homebrew's approach on package management is a bad smell to me. It gets broken by every other major OS update, it messes up your Python PATH for no good reason, it forces a lot of opinionated decisions on users if the maintainers think it benefits the majority(and ignores voice from minority)... But Homwbrew still wins because users really like it. It is that simple. With its popularity and the strong community, it will continue to be the top choice for most of the mac users. Max Howell may not be a rock star programmer in my mind, but I have no doubt that he could've been a very successful product manager.
Personally I don't plan to switch from macports to homebrew any time soon, but I stopped grumbling about how bad it is years ago.
1. https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
I am using brew because it works, as simple as that. If in 99% of cases I can type "brew install stuff" and it installs stuff, I am happy. Does it have outliers? Sure, as pretty much any other software, sometimes it breaks. But it delivers environment where I can install stuff without wasting my time on boring crap like figuring out how to build it and resolve conflicts with other crap - it's enough for me. Even if it only does that in 99% of cases, still much better than not having it.
As I see it, a major problem in software is that when you have a problem, it's often not clear who or what is at fault. Let's say my laptop is slow, particularly when I have lots of browser tabs open. Should I blame:
1. My hardware?
2. My OS?
3. My web browser?
4. My browser extensions?
5. Websites?
6. The chat app I keep open in the background?
7. The Electron settings app for my RGB Keyboard?
8. My internet connection?
9. A virus?
10. "Technology", presumably alongside some wistful thoughts of "the good old days"?
Most users, even non-technical ones, are going to blame one of these things. And, more often than not, their conclusions will have more to do with marketing and happenstance than the actual cause
All of which is to say, that quote kind of bothers me. You cannot actually be focused on user experience while skimping on technical details. You may have created an experience in which users feel inclined to blame someone else, but that's not the same thing. You are the knowledgable developer, and your users are not.
1. My hardware?
2. My OS?
3. My web browser?
4. My browser extensions?
5. Websites?
6. The chat app I keep open in the background?
7. The Electron settings app for my RGB Keyboard?
8. My internet connection?
9. A virus?
10. "Technology", presumably alongside some wistful thoughts of "the good old days"?
Most users, even non-technical ones, are going to blame one of these things. And, more often than not, their conclusions will have more to do with marketing and happenstance than the actual cause
All of which is to say, that quote kind of bothers me. You cannot actually be focused on user experience while skimping on technical details. You may have created an experience in which users feel inclined to blame someone else, but that's not the same thing. You are the knowledgable developer, and your users are not.
Have you tried uninstalling Chrome? I hear it can make your WindowServer go wild :P
More seriously, though, this is why I hate people who use software like Electron and claim their users can't notice: of course they can, they just complain that their computer is slow because they can't pinpoint it on your app. As a developer who knows better, your entire charade depends on ignorant users being unable to point the blame at you for what you have done to them. Combine this with the lock-in typical of today where users are resigned to use your software even if they don't particularly want to and now the people who do know what you're doing can't do anything about it either.
More seriously, though, this is why I hate people who use software like Electron and claim their users can't notice: of course they can, they just complain that their computer is slow because they can't pinpoint it on your app. As a developer who knows better, your entire charade depends on ignorant users being unable to point the blame at you for what you have done to them. Combine this with the lock-in typical of today where users are resigned to use your software even if they don't particularly want to and now the people who do know what you're doing can't do anything about it either.
Those were one of the reasons, but I believe the biggest reason was MacPorts didn't install from binary archive and requires building everything from source in its early days (in the old BSD port tradition). Binary archives were added to MacPorts in 2011 with MacPorts 2.0, but a lot of people (me included) has already moved to Homebrew, leaving MacPorts with an impression of old, slow, and make your Mac fry an egg.
MacPorts these days behaves similar to Homebrew by installing from binary archives by default and only build from source when binary archive is not available. This vastly improved the experience, but the old impression remains for those who got burned (literally for some) by MacPorts. 10 years is a long time, and MacPorts has improved a lot since then.
MacPorts these days behaves similar to Homebrew by installing from binary archives by default and only build from source when binary archive is not available. This vastly improved the experience, but the old impression remains for those who got burned (literally for some) by MacPorts. 10 years is a long time, and MacPorts has improved a lot since then.
MacPorts does also still drop to compiling from source more often than Homebrew. But that’s mostly because they take a more conservative legal approach towards the GPL—for instance, they won't distribute binaries of any GPL software that links with OpenSSL.
Also, ports for older/ancient versions of OS X are frequently source-only, but since Homebrew doesn’t support such systems at all, it's not really a fair comparison.
(As an aside, MacPorts must have the most incredible legacy support of any Mac project, ever. They had ARM working within a week of the M1’s release, largely because all of the infrastructure for multi-arch was already in place—to support users on PowerPC!)
Also, ports for older/ancient versions of OS X are frequently source-only, but since Homebrew doesn’t support such systems at all, it's not really a fair comparison.
(As an aside, MacPorts must have the most incredible legacy support of any Mac project, ever. They had ARM working within a week of the M1’s release, largely because all of the infrastructure for multi-arch was already in place—to support users on PowerPC!)
> Also, ports for older/ancient versions of OS X are frequently source-only, but since Homebrew doesn’t support such systems at all, it's not really a fair point of comparison.
On an old, unsupported, system homebrew drops down to compiling. just the other day it compiled for four hours just to update one program. kinda infuriating really since there are downloads for those packages still.
On an old, unsupported, system homebrew drops down to compiling. just the other day it compiled for four hours just to update one program. kinda infuriating really since there are downloads for those packages still.
I'm surprised it still works, to be honest–Homebrew is usually fairly aggressive about dropping support for older systems.
We don’t support any scenario where things are built from source (i. e. we won’t help you if things break) so technically support has indeed been dropped.
Is there no way to enable downloads of builds in homebrew on those systems with the caveat that perhaps it'd have to go back to compiling if there aren't any?
The bottles no longer exist.
The nodes that used to build High Sierra bottles have been re-commissioned to build Big Sur bottles.
The nodes that used to build High Sierra bottles have been re-commissioned to build Big Sur bottles.
[deleted]
This is a weird take.
Homebrew not only installed from source for a long time, when they implemented installing prebuilt binaries, they half-assed the dependency resolution of it, so the binary version of a package would always end up requiring the binary version of the first of any alternate dependencies (ie if A requires B or C, binary pkg A will always require binary package B, and won’t accept C).
Homebrew not only installed from source for a long time, when they implemented installing prebuilt binaries, they half-assed the dependency resolution of it, so the binary version of a package would always end up requiring the binary version of the first of any alternate dependencies (ie if A requires B or C, binary pkg A will always require binary package B, and won’t accept C).
Ah, you're right. Now thinking back, I think it was how Homebrew reuse system libraries that make it a better experience than MacPorts at the time since it could cut over half of the building time (it prevent the situation where `port install sl` ended up having to build the entire gcc toolchain). This was actually why "reuse system library" were such a big deal back then. Bottle come much later than that.
The other downside to MacPorts' original way of building everything is that sometimes, for whatever reason, things just wouldn't build and getting help with that was thorny, particularly for those who'd just started dabbling in software development or CLI usage. Where a vet or moderately seasoned user might find the thrown error actionable, the new user would google the error, find a couple of semi-related but ultimately unhelpful archived mailing list threads from n years ago, and probably give up and find some other way to get the package they need.
Just today my new config for Emacs refused to build libgit. I could see the CMake error, but rather than figuring out how to fix it I just commented out that part of my config (resulting in slightly more overhead in magic). Even with many years of serious software development, I really don't like debugging build problems.
I used to use Fink and MacPorts for MacOS package management, but brew was so easy to use that it won me over.
I used to use Fink and MacPorts for MacOS package management, but brew was so easy to use that it won me over.
This is one reason why using Rust crates in cargo's current form irritates me, if I wanted that kind of experience I would be using Gentoo as daily driver.
All the other languages I use support binary libraries on their package managers.
All the other languages I use support binary libraries on their package managers.
I find it unfortunate that those two occupy the 1-2 in Mac packaging options. It never really got much attention, but I've always liked Rudix [0] better. The package selection is much worse and not really kept as up-to-date, but the installation mechanism is far superior to Homebrew and MacPorts (and even Fink). It uses actual packages (the kind that Installer.app understands) so it integrates much more cleanly with the Mac ecosystem and packages installed without using the package manager. Compared to the other options, it's an administrator's dream in a managed environment since all the first-party Apple tools for managing a fleet of Macs just work. Also, users who don't want to install the actual rudix tool can simply download the packages and install using using Installer.app (which they may never even realize they're running because it opens automatically when opening a .pkg file).
Unfortunately, most Mac users have never even heard of it and it doesn't really have the momentum or mindshare necessary to have a complete, up-to-date list of packages.
[0] https://rudix.org/
Unfortunately, most Mac users have never even heard of it and it doesn't really have the momentum or mindshare necessary to have a complete, up-to-date list of packages.
[0] https://rudix.org/
Why leave out nix? It's been a good alternative that works similarly on Linux too for unified environment.
I hate Linuxbrew when it tries to install stuff in a weird place that is /home/linuxbrew/.linuxbrew/ and as soon as you try to change the installation path, half of your packages starts compiling and since it's not the major way to do things, it often breaks and can't even compile.
I don't like scaring other users on the same server creating stuff at some bizarre location.
No idea how they didn't just settle in /use/local/ as it does on Mac or just use /opt/brew/ like a sane choice would be.
I hate Linuxbrew when it tries to install stuff in a weird place that is /home/linuxbrew/.linuxbrew/ and as soon as you try to change the installation path, half of your packages starts compiling and since it's not the major way to do things, it often breaks and can't even compile.
I don't like scaring other users on the same server creating stuff at some bizarre location.
No idea how they didn't just settle in /use/local/ as it does on Mac or just use /opt/brew/ like a sane choice would be.
Rudix seems interesting, so I just installed the nasm .pkg as an experiment. There are several things I don't understand yet. How is a package uninstalled? If there is an updated package, does the whole process of downloading and clicking through Installer.app have to be repeated? Also, is there an automated way to install a large selection of packages at once?
There is an actual rudix package that has install/uninstall, including for itself.
Otherwise you’re using the somewhat cumbersome process of backing out a package based on the receipt. It’s doable, but mostly requires some googling to find the correct incantation.
Otherwise you’re using the somewhat cumbersome process of backing out a package based on the receipt. It’s doable, but mostly requires some googling to find the correct incantation.
Can't upvote enough. Rudix is the only package manager that really meshes with the platform, instead of trying to create its own weird linux (or bsd) hybrid ecosystem. I used it heavily a decade ago, but sadly it never really took off.
> I hate to say it, but if this was a race (?), Homebrew won. Thankfully we all still have the choice to use MacPorts if we want, but there's no point in being mean about Homebrew at this point either.
Definitely, plus there's also Nix and pkgsrc now, it's not like there's no alternative. And that's one race I lost trying to take the matter in my own hands with ArchMac[0] out of frustration with the limitations I faced with MacPorts and Fink, then Homebrew, so I pulled the plug[1] and trim the bills.
If anyone wants to take over just reach out.
[0]: https://www.archmac.org/
[1]: https://lna7n.org/2020/01/06/pulling-the-plug-on-archmac.htm...
Definitely, plus there's also Nix and pkgsrc now, it's not like there's no alternative. And that's one race I lost trying to take the matter in my own hands with ArchMac[0] out of frustration with the limitations I faced with MacPorts and Fink, then Homebrew, so I pulled the plug[1] and trim the bills.
If anyone wants to take over just reach out.
[0]: https://www.archmac.org/
[1]: https://lna7n.org/2020/01/06/pulling-the-plug-on-archmac.htm...
I'd never heard of Arch Mac until I read this comment, but reading your post about pulling the plug gave me chills.
I could tell that you poured a lot into this project, and I feel a surprising degree of wistfulness over your decision to abandon it.
I hope whatever you're working on now is as fulfilling as you wanted Arch Mac to be.
I could tell that you poured a lot into this project, and I feel a surprising degree of wistfulness over your decision to abandon it.
I hope whatever you're working on now is as fulfilling as you wanted Arch Mac to be.
I still prefer MacPorts over Homebrew. However, like you said, Homebrew's marketing in the form of embedded into tutorials and setup's helped push them to where they are now.
Almost every Ruby on Rails tutorial I've seen in the last decade used Homebrew over MacPorts.
I found MacPorts just before Homebrew was a thing. I figure since Mac OS was BSD based, why not go with the traditional portage way.
I preferred my optional packages to be installed in /opt. I preferred MacPorts.
Sadly, in the last 3-4 years, Homebrew has been leading the charge, adding more bleeding edge package versions and just doing a better job of maintaining the formulas for install.
Happy to see it. I think for python/go/ruby devs they will continue to prefer Homebrew simply because the tutorials they learned from prefer it. It's a feedback loop.
Almost every Ruby on Rails tutorial I've seen in the last decade used Homebrew over MacPorts.
I found MacPorts just before Homebrew was a thing. I figure since Mac OS was BSD based, why not go with the traditional portage way.
I preferred my optional packages to be installed in /opt. I preferred MacPorts.
Sadly, in the last 3-4 years, Homebrew has been leading the charge, adding more bleeding edge package versions and just doing a better job of maintaining the formulas for install.
Happy to see it. I think for python/go/ruby devs they will continue to prefer Homebrew simply because the tutorials they learned from prefer it. It's a feedback loop.
MacPorts seem to be very “user” friendly for people with Unix and/or Gentoo (maybe a bit Arch too) background. I have experience with all three and when I needed to decide in between HomeBrew and MacPorts, it was very simple choice. I tried both to get the actual experience and stuck with MacPorts.
All the naming in HomeBrew was just too confusing too me.
Gentoo is probably the most user hostile Linux distribution I can think of other than ones purposely austere for learning (LFS) or parody (Suicide Linux).
If Mac Ports requires that level of knowledge to be user friendly it’s no surprise they lost.
If Mac Ports requires that level of knowledge to be user friendly it’s no surprise they lost.
If Gentoo makes your particular computer goal easier to achieve, I don't think it's "hostile".
Most people will never need Gentoo or want to use it, but for those with either a need or a desire for a meta-distribution, Gentoo does a pretty good job. I don't think calling it "user hostile" is quite right.
I think it's been partially supplanted by other package managers now like Nix/NixOS and even (IMO) XBPS/Void, but Portage does an alright job.
Most people will never need Gentoo or want to use it, but for those with either a need or a desire for a meta-distribution, Gentoo does a pretty good job. I don't think calling it "user hostile" is quite right.
I think it's been partially supplanted by other package managers now like Nix/NixOS and even (IMO) XBPS/Void, but Portage does an alright job.
I used Gentoo for a while and mostly liked it. There was one reason I stopped using it -- dependency conflicts. Every time you update, there's a new set of conflicts that you have to personally untangle.
By any other metric, I would consider it more user-friendly than average. For example, I was very favorably impressed when (not knowing what I was doing), I gave the command to uninstall libc, and after confirming that I really wanted to do that, I was allowed to.
By any other metric, I would consider it more user-friendly than average. For example, I was very favorably impressed when (not knowing what I was doing), I gave the command to uninstall libc, and after confirming that I really wanted to do that, I was allowed to.
Ha, what was it, emerge -e world ? Or something like that. It’s been like 15 years since I did that.
The community feel was pretty good. Excellent documentation/wiki. And it was by far the best Linux education I could have ask for back in those days. I’m happy ...
The community feel was pretty good. Excellent documentation/wiki. And it was by far the best Linux education I could have ask for back in those days. I’m happy ...
I used gentoo for a few years and found it to be very pleasant, with a great wiki. The only reason I ever stopped using it is because I realized how senseless it was to build everything from source on a laptop with questionable thermal characteristics. Running laptop fans full tilt for hours on end a few times a week evidently exceeds their expected duty cycle, who'd have thunk, but I had to replace the fan in my T60p twice before I learned this lesson. Building everything with Macports would have the same problem, except worse because mac laptops were never as easy to repair as thinkpads, particularly not in recent years.
No, it doesn’t need more knowledge. It’s pretty simple to use. I was just pointing out similarity in concept. Something other users may have experienced in the past.
I don’t agree with Gentoo being hostile :). Complex and educational, sure. But if anything, you can shape it exactly you want it!
If you meant the community, wait until you meet the wrath of ArchLinux forums LOL
Hostile, as in not everything is mouse clicky for you?
It was a great learning experience nearly 20 years ago.
It's just not for you.
It was a great learning experience nearly 20 years ago.
It's just not for you.
It was a great learning experience for me too.
It's just not user friendly.
It was my first experience with linux in 2003, going through some 80 page wiki to get things configured and built. Learning how to configure an fstab file.
Hostile as in everything requires following a multipage guide of commands and manual configuration that often didn't quite work. Also when I asked on the forum I was told they didn't want more users, but more skilled users (I was 12).
So not really mouse clicky, more that basic functionality takes enormous effort to get working and the community at the time wasn't great.
It's just not user friendly.
It was my first experience with linux in 2003, going through some 80 page wiki to get things configured and built. Learning how to configure an fstab file.
Hostile as in everything requires following a multipage guide of commands and manual configuration that often didn't quite work. Also when I asked on the forum I was told they didn't want more users, but more skilled users (I was 12).
So not really mouse clicky, more that basic functionality takes enormous effort to get working and the community at the time wasn't great.
I've never used MacPorts. Go figure, I just realized that "MacPorts" means "bsd ports for mac". I'll have to try it sometime and see if I prefer the look and feel of MacPorts.
I've found it rather easy to use, I've only been a mac user for a couple of years. I've not had any problems with updates either. I switched from brew fairly quickly when brew told me I couldn't install packages because they weren't "safe" even though I knew they were in fact fine because I've used them for years on linux.
If you liked bsd ports, you are probably going to like MacPorts too. I only wish they better advertise how to set up MacPorts without sudo/within users homedir. I have been using it like that for 4 years and it works great. No worries about affecting mac core bins. Highly recommend if you want to just test it out
[deleted]
I don't recall how I came across it but remember well the relief after using it the first time. It was the first package manager on MacOS that worked and made installing common tools painless. With MacPorts, fink etc it felt like it would have been better to built from source yourself.
I agree with this (other than maybe hating to see Homebrew “win”). And I’ll add:
And although I’m not arguing Homebrew is above reproach or critique, some of the criticism here seems both a little unfounded and a little bit ignorant (either willfully or because people just don’t know/remember) about the state of package managers BEFORE Homebrew. Like you, I used MacPorts/Darwinports and Fink for years before Homebrew was a thing and have immense respect for all three of those projects (even though DP merged with MP over a decade ago, my mind still sees them as separate things) and the massive role they played in my own life and development as a developer, but Homebrew didn’t just pop-up and supplant the existing options and through nefarious means.
At the time that it came to existence, despite the very good existing options, those communities and their progress had stagnated — at least from the perspective of the end user. There was a wealth of older packages, but newer stuff wasn’t there. And the death of PPC with Snow Leopard hit subsets of that community hard. It wasn’t just that Homebrew was easier to use and install (though it was, a bit), it was that it had more modern and more frequently updated packages.
I distinctly remember when Homebrew first arrived, my initial reaction was, “why do I need this, I already have MacPorts?” But then I used it and found that people were bottling up newer stuff at a much more rapid pace and the tools embraced by that community were modern and frankly, to an outsider, much more accessible. As you said, choosing GitHub over MacForge or whatever was a great choice too.
MP has had a renaissance of sorts over the years which has been amazing to see. I think having options is awesome. But Homebrew was very much filling a void for some beloved projects that had fallen behind. It’s hard to win that momentum back, once the community (including a whole generation of new users) goes to the new thing.
We’ve seen that with Mac text editors too. TextMate, to me, is still one of the best editors I’ve ever used and I would argue is one of the most influential software applications of the aughts. But as it faced all of its challenges to move to 2.0 (the feature creep, the technical challenges, the scope changes), it created a window for Sublime to come in and take the the extension community (which was really pioneered in the way that it worked by TextMate), and thus the userbase with it. And when Sublime faced similar challenges in its own troubled releases (for some of the same but also different reasons that TextMate had), we again saw momentum shift to VS Code.
And although I’m not arguing Homebrew is above reproach or critique, some of the criticism here seems both a little unfounded and a little bit ignorant (either willfully or because people just don’t know/remember) about the state of package managers BEFORE Homebrew. Like you, I used MacPorts/Darwinports and Fink for years before Homebrew was a thing and have immense respect for all three of those projects (even though DP merged with MP over a decade ago, my mind still sees them as separate things) and the massive role they played in my own life and development as a developer, but Homebrew didn’t just pop-up and supplant the existing options and through nefarious means.
At the time that it came to existence, despite the very good existing options, those communities and their progress had stagnated — at least from the perspective of the end user. There was a wealth of older packages, but newer stuff wasn’t there. And the death of PPC with Snow Leopard hit subsets of that community hard. It wasn’t just that Homebrew was easier to use and install (though it was, a bit), it was that it had more modern and more frequently updated packages.
I distinctly remember when Homebrew first arrived, my initial reaction was, “why do I need this, I already have MacPorts?” But then I used it and found that people were bottling up newer stuff at a much more rapid pace and the tools embraced by that community were modern and frankly, to an outsider, much more accessible. As you said, choosing GitHub over MacForge or whatever was a great choice too.
MP has had a renaissance of sorts over the years which has been amazing to see. I think having options is awesome. But Homebrew was very much filling a void for some beloved projects that had fallen behind. It’s hard to win that momentum back, once the community (including a whole generation of new users) goes to the new thing.
We’ve seen that with Mac text editors too. TextMate, to me, is still one of the best editors I’ve ever used and I would argue is one of the most influential software applications of the aughts. But as it faced all of its challenges to move to 2.0 (the feature creep, the technical challenges, the scope changes), it created a window for Sublime to come in and take the the extension community (which was really pioneered in the way that it worked by TextMate), and thus the userbase with it. And when Sublime faced similar challenges in its own troubled releases (for some of the same but also different reasons that TextMate had), we again saw momentum shift to VS Code.
> I don't think Homebrew took the field purely through sneaky marketing or n00b decisions alone.
The Homebrew team was using a lot of FUD regarding MacPorts when Homebrew started. It's actually funny because they were criticizing some of MacPorts decisions which they then had to implement when they finally realized they were the correct engineering decisions years later.
The Homebrew team was using a lot of FUD regarding MacPorts when Homebrew started. It's actually funny because they were criticizing some of MacPorts decisions which they then had to implement when they finally realized they were the correct engineering decisions years later.
[deleted]
Homebrew and Metaspoit prompted me to learn Ruby. It’s an excellent and well-suited language for that type of DSL
I used both MacPorts and Fink prior to Homebrew being released. The fact that it was able to do binary archive installs, and then later Homebrew Cask just made it a far friendlier package manager. I've added a few formulas over the years and am happy to see it continue!
i honestly don't know the backstory on why you "hate to say it", and personally was a NeXT developer 25 years ago which I mention for context that I feel I missed out on something preferable in MacPorts, having found homebrew adequate.
No real backstory I guess. I found Homebrew unpleasant to use for a lot of the reasons gone through in this thread -- mostly just the "rolling distro" nature of it -- so I was a dedicated user of MacPorts. My experience is probably further biased by the fact that I was using the package manager on OS X to deal with Python stuff at the time, so the versioning issues definitely bit me. But at some point, using MacPorts just started to feel like swimming against the tide.
Dear Homebrew maintainers,
one simple effing thing: thank you! For all the hard work and the sheer pleasure Homebrew adds to the experience of developing software on a Mac.
one simple effing thing: thank you! For all the hard work and the sheer pleasure Homebrew adds to the experience of developing software on a Mac.
The majority of the ports and software I want installed are essentially Unix/Linux/GNU environment tools.
Macports has always seemed to me to be a more "unix-y" way of doing that, and it works politely with Apple's ways on top of the Unix core (eg locking down the system volume).
It also has a very nice "select" and "variants" system that allows you to have multiple versions of a package as well as packages with more or less functionality (eg integrating with the MacOS keychain etc).
When I first got into Macs (only around 5 years ago), I looked at both homebrew and macports and as soon as I saw homebrew blasting stuff into /usr/local while macports neatly put everything in /opt, I was convinced to go with macports. I also had previous experience with the BSD's port systems, which helped push me towards macports.
But I'm open to being convinced about homebrew, although I've never needed something that it had that macports didnt.
Macports has always seemed to me to be a more "unix-y" way of doing that, and it works politely with Apple's ways on top of the Unix core (eg locking down the system volume).
It also has a very nice "select" and "variants" system that allows you to have multiple versions of a package as well as packages with more or less functionality (eg integrating with the MacOS keychain etc).
When I first got into Macs (only around 5 years ago), I looked at both homebrew and macports and as soon as I saw homebrew blasting stuff into /usr/local while macports neatly put everything in /opt, I was convinced to go with macports. I also had previous experience with the BSD's port systems, which helped push me towards macports.
But I'm open to being convinced about homebrew, although I've never needed something that it had that macports didnt.
I used to recommend Homebrew but stopped some time ago (v2, perhaps?) when they hard-removed all build customization/options in order to make it easier to develop bottles and close out GitHub issues (on their end) while severely restricting what users could do, taking away a lot of power and freedom that was previously available. Much more inline with the Apple line of thinking, but that’s kind of the reason people wanted a *nix-esque package manager, no?
Why is it bad that homebrew puts files in /usr/local?
Edit: They use /opt if you're on Apple Silicon https://github.com/Homebrew/brew/blob/master/docs/Installati...
Edit: They use /opt if you're on Apple Silicon https://github.com/Homebrew/brew/blob/master/docs/Installati...
There's nothing wrong with installing packages into /usr/local, but brew turns /usr/local into a git repository and IMO that is wrong. Also, brew acts like it's made for a single user, as it changes files and directories to be owned by the user running it, but /usr/local is a system directory. When I install brew, I always put it into my home directory instead of /usr/local.
It turns /usr/local/Homebrew into a git repository; not /usr/local itself. Whatever it links into /usr/local/{bin,include,lib,sbin,share} is just a symlink into /usr/local/Cellar.
Are you sure about that? I currently have it installed in ~/brew and commands link from ~/brew/Cellar into ~/brew/bin and there is a .git directory in ~/brew. I used to put it in /usr/local and it irked me that there was a /usr/local/.git. That was the main reason I stopped putting it there.
They used to put the repo in /user/local but moved it to /usr/local/Homebrew a few years ago.
Yes, I'm sure, it exactly like that on this very machine where I type this comment. However, the Apple Silicon version installed into /opt/homebrew creates the repo directly in its prefix, just like yours installed into ~/brew. Here the content of Homebrew dir is mixed with Cellar, Frameworks and Caskroom, which are normally one directory up. So it looks like it behaves differently when the prefix is /usr/local.
How's the experience putting it under your home? I assume many packages need to be compiled but does everything compile fine?
My first experience with homebrew (as a non-mac user) was setting up a build agent a few years ago. It seemed like a nice way to get everything going, as well as being analogous to the ways it was setup on other OSes (using packages to manage the SDKs/tooling).
I think my mistake was treating it like any other unix-y [multi-user] system, because I installed everything with one account, then created a dedicated 'build' account for the agent to run as -- exactly as our linux (and even, ahem, Windows) agents were setup. This caused all kinds of failures for the 'build' user as everything was owned by and had permissions setup for the first user.
I came away kind of disgusted at the horrible patterns in use. Windows has spent two decades cleaning up that mistake, and here's a comparably new system making the same, awful mistakes?
User-writable/owned stuff goes in ~. Period.
I think my mistake was treating it like any other unix-y [multi-user] system, because I installed everything with one account, then created a dedicated 'build' account for the agent to run as -- exactly as our linux (and even, ahem, Windows) agents were setup. This caused all kinds of failures for the 'build' user as everything was owned by and had permissions setup for the first user.
I came away kind of disgusted at the horrible patterns in use. Windows has spent two decades cleaning up that mistake, and here's a comparably new system making the same, awful mistakes?
User-writable/owned stuff goes in ~. Period.
/usr/local was originally for local (ie host) software that wasn't in /usr/{bin,lib,sbin,slib...} or /{bin,lib,sbin,slib...}.
Then GNU took over and made some opinionated choices about how those subdirectories were to be used, which is fine.
However, because /usr/local is under /usr, it meant that it was more difficult to mount /usr as read-only or shared. There is also the issue of whether files under /usr/local should be owned by non-system users.
A while back, the creation of /opt and /opt/{some-app} (and /var/opt/{some-app} became a way to avoid writing into /usr and also made it possible to mount applications with their code as read only with writable locations under /var.
So I've taken writing to /usr/local as a packaging smell these days, purely to avoid writing into /usr.
Then GNU took over and made some opinionated choices about how those subdirectories were to be used, which is fine.
However, because /usr/local is under /usr, it meant that it was more difficult to mount /usr as read-only or shared. There is also the issue of whether files under /usr/local should be owned by non-system users.
A while back, the creation of /opt and /opt/{some-app} (and /var/opt/{some-app} became a way to avoid writing into /usr and also made it possible to mount applications with their code as read only with writable locations under /var.
So I've taken writing to /usr/local as a packaging smell these days, purely to avoid writing into /usr.
I can’t even begin to imagine how much value Max Howell (creator of Homebrew) has added to the world. It’s the recommended package manager at every place I’ve worked at and saves so much headache.
I use Linux at home and package managers like AUR are great, but macOS is where the users are.
I use Linux at home and package managers like AUR are great, but macOS is where the users are.
Contrarian view here: brew fucking sucks. It’s the worst package manager I’ve used for doing random unwanted updates at odd times. Someone else would have filled the void if homebrew hadn’t shown up, and it would hopefully have been better. I hate that brew is good enough that it’s got some kind of local maximum such that there’s no replacement forthcoming. There, I said it.
Homebrew maintainer here: I'm sorry that we don't meet your expectations.
Two things for your consideration:
1. It's uniquely visible among system package managers. When people have problems with a package in `apt` or `dnf`, they find a community or third-party repository for the package or bug the upstream directly. By contrast, Homebrew has always been visible on GitHub, does not require a special login to a bugtracker on some random domain, and thus receives direct community support volume that we need to address.
2. Homebrew is not an official system package manager. We operate at Apple's whim, which generally ranges between neutral disinterest and actively trying to remove parts of the macOS userspace that we rely on. Many of our changes over the last decade (installing our own Ruby, rolling back custom source options) can be directly traced back to changes that Apple imposes that produce disproportionately greater maintenance effort from us.
Two things for your consideration:
1. It's uniquely visible among system package managers. When people have problems with a package in `apt` or `dnf`, they find a community or third-party repository for the package or bug the upstream directly. By contrast, Homebrew has always been visible on GitHub, does not require a special login to a bugtracker on some random domain, and thus receives direct community support volume that we need to address.
2. Homebrew is not an official system package manager. We operate at Apple's whim, which generally ranges between neutral disinterest and actively trying to remove parts of the macOS userspace that we rely on. Many of our changes over the last decade (installing our own Ruby, rolling back custom source options) can be directly traced back to changes that Apple imposes that produce disproportionately greater maintenance effort from us.
Point 2 here is huge. If Apple cared about open source or cross-platform developers, they would pay at least one full-time Homebrew developer and upgrades would be smooth. It speaks volumes that they are swimming in money and can't be bothered to make a token gesture.
> It speaks volumes that they are swimming in money and can't be bothered to make a token gesture.
I agree with a lot of the sentiment here, but I want to make one important correction: Apple has helped us. In particular, they gave us access to DTKs for the M1 and provided us with a liaison for the migration. We're very thankful for that help.
That being said, Apple is a massive company and they have their own development goals and velocity for macOS. They're not actively looking to break Homebrew, but they're also not going to halt everything for us.
I agree with a lot of the sentiment here, but I want to make one important correction: Apple has helped us. In particular, they gave us access to DTKs for the M1 and provided us with a liaison for the migration. We're very thankful for that help.
That being said, Apple is a massive company and they have their own development goals and velocity for macOS. They're not actively looking to break Homebrew, but they're also not going to halt everything for us.
Thanks for calling that out. This is totally unrelated to everything, but it's refreshing to see people giving credit -and thanks- to behemoth companies here on HN, with the proper nuance to also call out places they could have helped more (and the understanding of why they didn't). It's too easy, and common, to pile on the shortcomings. It struck me as a standout comment even in this generally polite community.
Apple swims in money and can't even be bothered to implement a hassle-free way of changing your Apple ID, especially if you own more than one device and even worse if you have 'Find My' enabled on them.
More than one person just last week got stuck in a loop where the system wants credentials for your old deactivated Apple ID. The solution isn't hard but the UX flow fucking sucks.
You must manually sign out of all devices using your old ID and sign in again. Except before you can do that you have to disable Find My. With the deactivated credentials again.
It shows the OLD email and wants the old password but you have to actually enter the NEW password in the dialogue so Find My deactivates and you can sign out.
More than one person just last week got stuck in a loop where the system wants credentials for your old deactivated Apple ID. The solution isn't hard but the UX flow fucking sucks.
You must manually sign out of all devices using your old ID and sign in again. Except before you can do that you have to disable Find My. With the deactivated credentials again.
It shows the OLD email and wants the old password but you have to actually enter the NEW password in the dialogue so Find My deactivates and you can sign out.
Apple has always been pretty cavalier with breaking things and also full of NIH syndrome. It works for point-n-click users which don't care which hardware or software they are clicking as long as it's shiny and pointy and clicky. But if you're a developer that cares about the OS plumbing, let alone relies on parts of it, Apple is not going to do you any favors.
The thing is efforts like homebrew is basically the only thing that keeps Apple platforms as a viable developer's platform (without it it'd be intolerable, as Apple has zero official solutions for managing software not coming in pointy-clicky Appstore packaging) - and given that macs are still popular among many developers, it's a mystery why Apple corporate pays so little attention to it. It's like they sold a car without any tires and wouldn't even acknowledge the existence of tire manufacturers, let alone how vital they are for the actual users of the product.
The thing is efforts like homebrew is basically the only thing that keeps Apple platforms as a viable developer's platform (without it it'd be intolerable, as Apple has zero official solutions for managing software not coming in pointy-clicky Appstore packaging) - and given that macs are still popular among many developers, it's a mystery why Apple corporate pays so little attention to it. It's like they sold a car without any tires and wouldn't even acknowledge the existence of tire manufacturers, let alone how vital they are for the actual users of the product.
> We operate at Apple's whim, which generally ranges between neutral disinterest and actively trying to remove parts of the macOS userspace that we rely on.
<sigh> I know you're not unique in this assessment or consequence, and that's truly a shame.
<sigh> I know you're not unique in this assessment or consequence, and that's truly a shame.
I think that #2 might not happen as often if Homebrew better conformed to a "UNIXy" philosophy. And to Apple's philosophy, because there is a sort of mentality to how they operate, even if you can't predict exactly what they'll do.
MacPorts hasn't had as many of these issues over the years, and I suspect that's largely down to mindset. Broadly speaking, MacPorts seems to have "first, do no harm" approach to almost everything. They don't install files in directories they didn't create, and they avoid depending on systems which are out of their control.
MacPorts hasn't had as many of these issues over the years, and I suspect that's largely down to mindset. Broadly speaking, MacPorts seems to have "first, do no harm" approach to almost everything. They don't install files in directories they didn't create, and they avoid depending on systems which are out of their control.
Yes. I'm really torn about brew. On the one hand, I hate to crap on the work that the maintainers have done, and it's clearly the best thing out there for macos. On the other hand, it's a terrible dictatorial piece of software that wants to command precisely how you use your computer; those same maintainers are actively hostile to users, as evidenced by the endless stream of nasty responses to issues, arbitrary changes to disable any functionality that they believe anyone has ever misused by their standards ever, etc. I pray daily that someone will fork it.
The decisions to enable auto update, the removal of `--with-foo` options, breaking the `brew list` command and the removal of `depends_on :x11` were all mistakes, as I see it. I have read loads of issues and pull requests to understand the reasoning but have yet to find arguments that I think justifies those breaking changes.
I get it, it's all made by volunteers, but I wish there was a package manager for macOS that was focused on professional users.
I wonder if the decision process in Homebrew has relied perhaps too much on analytics data leading to the dismissal/ignorance of features used primarily by users who have disabled analytics via the HOMEBREW_NO_ANALYTICS environment flag.
I get it, it's all made by volunteers, but I wish there was a package manager for macOS that was focused on professional users.
I wonder if the decision process in Homebrew has relied perhaps too much on analytics data leading to the dismissal/ignorance of features used primarily by users who have disabled analytics via the HOMEBREW_NO_ANALYTICS environment flag.
>it's a terrible dictatorial piece of software that wants to command precisely how you use your computer
I've also seen examples of where Homebrew is basically dictating on how to release your software as well. There was that one case where they decided to delete the formula for mpv since mpv didn't have a recent enough of a tagged release.
https://github.com/danielbair/homebrew-core/commit/b18f104f1...
There was also an instance with mpv where Homebrew devs got pissy about mpv not supporting Lua 5.3 and mpv devs got angry at Homebrew devs for asking to break existing user scripts to appease one package manager.
I've also seen examples of where Homebrew is basically dictating on how to release your software as well. There was that one case where they decided to delete the formula for mpv since mpv didn't have a recent enough of a tagged release.
https://github.com/danielbair/homebrew-core/commit/b18f104f1...
There was also an instance with mpv where Homebrew devs got pissy about mpv not supporting Lua 5.3 and mpv devs got angry at Homebrew devs for asking to break existing user scripts to appease one package manager.
That one doesn't seem unreasonable. They have a "we only support tagged releases" policy. mpv moved away from tagging releases for a bit, and their latest tagged release couldn't build on current MacOS. So they switched it to the part of their system (casks) that supports downloading and installing arbitrary binaries instead.
I think it's a fair conflict, too. For a package manager, saying "just download and compile master wherever it is right now" is rough, and I can understand them not wanting to have to look at mpv's repo and pick a good commit to pin as their "release". Offloading picking a stable release point to someone else is legitimate.
I think it's a fair conflict, too. For a package manager, saying "just download and compile master wherever it is right now" is rough, and I can understand them not wanting to have to look at mpv's repo and pick a good commit to pin as their "release". Offloading picking a stable release point to someone else is legitimate.
To add to what you said, the formula came back a week and a half later when they returned to tagging releases.
https://github.com/Homebrew/homebrew-core/commit/82a45025682...
https://github.com/Homebrew/homebrew-core/commit/82a45025682...
I suppose their hand was probably forced by Apple in some way, but simply offering binary downloads for mpv in particular is subpar. There are a lot of unusual options for mpv that, in my experience, don't get pulled into prebuilt binaries. For instance, last I checked, the prebuilt packages for mpv from homebrew didn't have librubberband support. LibRubberband is great, but to effectively integrate it into your workflow you need some userscripts that mpv doesn't ship with, so many users (including packagers evidently) may not see the value in it. When I was still using MacOS, I had to build mpv myself to enable it. My memory is hazy, but I think libarchive support was in a similar situation. Eventually I cut homebrew out of the picture and chose to build mpv myself, since homebrew wasn't helping at all, just getting in the way.
[deleted]
[deleted]
> dictatorial piece of software
Isn't that generally the point, for Apple consumers? At HN we have a skewed sample but I imagine for a lot of users (myself included), having an easy solution with configurations set for you is exactly what they want.
Isn't that generally the point, for Apple consumers? At HN we have a skewed sample but I imagine for a lot of users (myself included), having an easy solution with configurations set for you is exactly what they want.
That's what I want.
I build web apps for a living, and I used to do it by contracting. I don't have time, patience or interest for fiddly configuration. I want a mostly-good initial experience so I can get on with my work rather than mess about with my tools. I'm aware there's some gain to be had by knowing more about my tools, but the payoff isn't obvious enough to make me change my ways.
Thanks for being mostly-great, brew.
I build web apps for a living, and I used to do it by contracting. I don't have time, patience or interest for fiddly configuration. I want a mostly-good initial experience so I can get on with my work rather than mess about with my tools. I'm aware there's some gain to be had by knowing more about my tools, but the payoff isn't obvious enough to make me change my ways.
Thanks for being mostly-great, brew.
Exactly, it’s the same reason I use Mac instead of Linux. I want to make things. I don’t want to waste time fiddling with endless verbose details I don’t need to know
Yours, A Noob
Yours, A Noob
Not for developers, no. "Normal" Apple consumers have little reason to use brew.
I think that's a false dichotomy. I think there are plenty of "normal" Apple consumers who may not be an HN-level hacker but would still be considered "developers".
What is a "HN-level hacker"? I write code for a living and I read news on this website. Do I count?
I'm an apple "consumer" because I don't want to think about any hardware gotchas when I'm trying to do my job. That's the same thing I want out of my package manager, sensible defaults I don't have to think about so I can do real work instead.
I'm an apple "consumer" because I don't want to think about any hardware gotchas when I'm trying to do my job. That's the same thing I want out of my package manager, sensible defaults I don't have to think about so I can do real work instead.
Homebrew has clear value even if you aren't a developer. It's the best way to install a whole lot of software, not just dev tools.
I'm not a developer and I have plenty of reasons to use homebrew.
I already stopped using Mac, but for people still using Mac: you really should give nixpkgs a try.
+1. I’ve been using it for a while, and it fixes my problems with homebrew - mostly that homebrew breaks features every couple of weeks in small point releases, which you get automatically upgraded to
Auto upgrade sucks but it is possible to turn it off
But then what? You still have to deal with the mess when you do manual upgrades.
Nix seems to be the Crossfit of the computing world.
How do you know someone uses Nix? They'll tell you :D
How do you know someone uses Nix? They'll tell you :D
How does it "command you how to use your computer?" A brew formula is a simple ruby script that lists the packages dependencies, and calls "make; make install". Typically it allows you to set any autoconfig vars and remembers them for next time. This is literally just a thin layer of abstraction over grabbing the tarball and installing the software yourself.
Also brew does not stop you from installing a piece of software literally any other way you prefer if for some reason you don't like what the brew formula is doing, including just creating your own tap.
Also brew does not stop you from installing a piece of software literally any other way you prefer if for some reason you don't like what the brew formula is doing, including just creating your own tap.
I find Nix to work better on macOS than Homebrew, and it doesn't embed spyware in the package manager like Homebrew does.
Ah, this reminds me of how shitty the maintainers were to me when I said I was using hackintosh (for an issue that had nothing to do with it).
Apologies about that.
I’m sure none of us wants to be shitty to anyone.
It’s never ok when we are.
You left out the entire generation of developers who are totally disconnected from how systems work and think that "it runs on my machine" should be good enough.
Brew has lowered the bar enough that lots of folks simply don't have a clue how to deploy anything and worse, don't have a clue how to troubleshoot when something goes wrong in production.
Obviously it's a double-edged sword. It's good to not waste time configuring your workstation, but ultimately I'd argue in brew's case too good to be true.
Brew has lowered the bar enough that lots of folks simply don't have a clue how to deploy anything and worse, don't have a clue how to troubleshoot when something goes wrong in production.
Obviously it's a double-edged sword. It's good to not waste time configuring your workstation, but ultimately I'd argue in brew's case too good to be true.
This makes no sense. First, nobody deploys anything to macos in production. Second, dragging an icon the applications folder (pre-brew method) does not "connect you to how the system works".
I don't understand this critique. Is this a complaint about package managers in general, or is `brew install git` lowering the bar from `apt install git`?
It's about a trend of developers who don't know how to interact with their system beyond `brew X Y` and the disconnect between the software on their Mac and the software on a production system.
There's a huge disconnect between A & B so much so that it's created an entire role for people like me that otherwise shouldn't exist.
I've been in the industry long enough to see a decline in ability for lots of developers beyond kicking deployment over the wall for someone else to figure out (not that this didn't exist before).
Notice how many companies have dedicated DevOps roles in their ranks whereas everyone and their mother who is a practitioner has been saying since the very beginning that that's now how it should be.
There's a huge disconnect between A & B so much so that it's created an entire role for people like me that otherwise shouldn't exist.
I've been in the industry long enough to see a decline in ability for lots of developers beyond kicking deployment over the wall for someone else to figure out (not that this didn't exist before).
Notice how many companies have dedicated DevOps roles in their ranks whereas everyone and their mother who is a practitioner has been saying since the very beginning that that's now how it should be.
Your complaints seem to boil down to "get off my lawn" and it's rather tedious. what do you get out of it other than a feeling of superiority?
It's not at all. It's a reaction to the learned helplessness from colleagues I've had to work with. It's exhausting to be relied upon for everything, especially when the compensation isn't matched appropriately (although most management I've encountered have appropriately engineers who do disproportionate heavy lifting). Our industry needs to do better.
I don't buy the premise that package managers are the reason why companies need DevOps.
Software deployment has gotten complicated for a variety of reasons (containerization, micro-services, continuous integration, cargo-culting FAANG practices, etc). When I first started my career, I FTP'd my code changes into the single production server that ran both Apache and MySQL. Homebrew is not the reason I don't do that anymore.
Software deployment has gotten complicated for a variety of reasons (containerization, micro-services, continuous integration, cargo-culting FAANG practices, etc). When I first started my career, I FTP'd my code changes into the single production server that ran both Apache and MySQL. Homebrew is not the reason I don't do that anymore.
That's not really the argument that I'm making.
I am a deployment engineer.
Deployment is actually really easy.
I'd argue that it's not far off from FTPing your code changes over in terms of difficulty.
No, my argument is that more engineers today do not know how computers work. I'd even argue that many engineers would find FTPing over code changes to be too difficult (or they'd screw it up). My argument is that homebrew makes some amount of contribution (not 100% the reason for) engineers remaining ignorant about computers.
I am a deployment engineer.
Deployment is actually really easy.
I'd argue that it's not far off from FTPing your code changes over in terms of difficulty.
No, my argument is that more engineers today do not know how computers work. I'd even argue that many engineers would find FTPing over code changes to be too difficult (or they'd screw it up). My argument is that homebrew makes some amount of contribution (not 100% the reason for) engineers remaining ignorant about computers.
Homebrew was the first package manager where I actually looked under the covers because everything was pretty easy to follow. I regularly use 'brew edit <formula>' just to see how something is built. I don't see how brew obscures the internals of my computer at all.
While I sympathize, I think that train left long time ago.
I had that aha moment, when during early 2000s I found myself explaining to C++ developer what linker is and what exactly it does. Until then, it was just the thing that VC++ did as the last step after clicking the Build menu item.
It certainly didn't improve since then.
I had that aha moment, when during early 2000s I found myself explaining to C++ developer what linker is and what exactly it does. Until then, it was just the thing that VC++ did as the last step after clicking the Build menu item.
It certainly didn't improve since then.
Do you know how to directly 'talk' to the CPU or GPU? Do you build everything from source? Are you comfortable writing assembly? Have you recently soldered shit or built a PC from scratch?
Yes, when it makes sense to, yes and yes.
I'd be happy to work with people who know system calls & exit codes though. And basic network protocols. And how to read an RFC.
I'd be happy to work with people who know system calls & exit codes though. And basic network protocols. And how to read an RFC.
> Notice how many companies have dedicated DevOps roles in their ranks whereas everyone and their mother who is a practitioner has been saying since the very beginning that that's now how it should be.
I dunno who says that but they're dead wrong. I'm working as a dev somewhere with a dedicated DevOps finally after years of being dev + ops (+dba +sysadmim +qa) and I can't tell you how much of a relief it is to have other people shoulder that stuff so I don't have to think about it.
I understand your point that devs who have a higher level understanding of systems and deploy pipelines and such are probably able to write good systems themselves, but when it comes to the humans doing the work? I absolutely love having it separated.
I dunno who says that but they're dead wrong. I'm working as a dev somewhere with a dedicated DevOps finally after years of being dev + ops (+dba +sysadmim +qa) and I can't tell you how much of a relief it is to have other people shoulder that stuff so I don't have to think about it.
I understand your point that devs who have a higher level understanding of systems and deploy pipelines and such are probably able to write good systems themselves, but when it comes to the humans doing the work? I absolutely love having it separated.
It feels nice but organizations with cross-functional teams are outmaneuvering yours and probably by at least 3x.
I'd rather work harder at a business that succeeds and has equity that's worth a damn.
I'd rather work harder at a business that succeeds and has equity that's worth a damn.
That's fine, I'd rather work on stuff I enjoy and have a life outside of work.
Well, to be clear, developers who say "it runs on my machine" aren't a "new generation of developers" so much as "bad software developers".
There's no world where that excuse is okay. It's also not all that related to Homebrew, though...
There's no world where that excuse is okay. It's also not all that related to Homebrew, though...
Not everyone wants to troubleshoot things in production. In fact I’d argue most people dont want to do that.
I’d certainly prefer to stay away from that type of hassle when I’m just trying to install a random package.
I’d certainly prefer to stay away from that type of hassle when I’m just trying to install a random package.
Nobody's saying you should want to.
This is a conversation about ability level.
This is a conversation about ability level.
"Someone else would have filled the void if homebrew hadn’t shown up, and it would hopefully have been better."
MacPorts and fink existed before homebrew took over, and they weren't better. That's why homebrew took over.
MacPorts and fink existed before homebrew took over, and they weren't better. That's why homebrew took over.
But Homebrew wasn't (and isn't) better than MacPorts, either.
They both work well (we can and do quibble about the internal mechanics of each), and appeal to different groups of people.
My theory is that Homebrew was announced at exactly the right time in the MacOS adoption curve. A huge number of new users arrived with no existing knowledge of MacPorts or Fink. Most of them didn't know they needed a package manager at first, but when the momentum picked up, Homebrew was the new option with a better web page, a more collaborative working model, and hosted at GitHub (also ascendant).
I'd also argue that similar factors were involved in Linux's popularity over BSD in the 1990s.
Timing, environment, adequacy, and luck. All are required. Superiority is not.
They both work well (we can and do quibble about the internal mechanics of each), and appeal to different groups of people.
My theory is that Homebrew was announced at exactly the right time in the MacOS adoption curve. A huge number of new users arrived with no existing knowledge of MacPorts or Fink. Most of them didn't know they needed a package manager at first, but when the momentum picked up, Homebrew was the new option with a better web page, a more collaborative working model, and hosted at GitHub (also ascendant).
I'd also argue that similar factors were involved in Linux's popularity over BSD in the 1990s.
Timing, environment, adequacy, and luck. All are required. Superiority is not.
About 11 years ago I moved over to then OS X and Homebrew was very new compared to MacPorts at the time. I started with the more established MacPorts, but quickly became frustrated with how many broken and outdated packages were hosted on MacPorts. So I moved over to Homebrew and haven't looked back.
This is not to say that Homebrew is perfect; there's lots of big and little things I'd change. But I'd argue that at least at the inflection point of its introduction, Homebrew definitely solved a problem I was having with its competition. Timing helped for sure, but in my experience it won on technical merits.
This is not to say that Homebrew is perfect; there's lots of big and little things I'd change. But I'd argue that at least at the inflection point of its introduction, Homebrew definitely solved a problem I was having with its competition. Timing helped for sure, but in my experience it won on technical merits.
I'm in that same boat. Homebrew irks some people, but for me it's always just worked to the point that I just don't have to think about it, ever. That's what I really want from a package manager: to be able to forget that it's there and start taking it for granted.
I used MacPorts before hombrew. Homebrew "just worked", MacPorts sucked.
Maybe I was too dumb to use MacPorts, but all other MacPort used I knew back then all moved to homebrew very quickly.
Maybe I was too dumb to use MacPorts, but all other MacPort used I knew back then all moved to homebrew very quickly.
This, so much this. I tried to use MacPorts. It was pulling teeth every time. Brew was a It Just Works breath of fresh air.
I agree that it's a very opinionated tool, and note that those opinions fit in well with the Mac ecosystem. They aren't as good a fit for Linux or Windows.
I agree that it's a very opinionated tool, and note that those opinions fit in well with the Mac ecosystem. They aren't as good a fit for Linux or Windows.
I think often 'it just works' and 'opinionated' goes hand in hand. Without choosing what to say no to, you create infinite workload with finite amounts of people and thus something breaks, somewhere.
Yep, I have to agree. I started using a mac about 11-12 years ago. Homebrew was new. At the time MacPorts was the "defacto" package manager and Homebrew was the "new kid on the block" or "experimental" one.
I started with Macports and it never did what I wanted it to. Packages were broken and it required me to do a lot of stuff that I didn't understand. A friend told me that he had recently done all the same installs on Homebrew and it was easy. So I gave Homebrew a try and the exact same packages installed easily and quickly. Homebrew has only gotten easier to use since then.
Maybe I am just not doing anything complicated enough with Homebrew to run into the issues other people have had, but my experience with Homebrew has been a breeze. I really don't have any complaints. I'd maybe prefer if packages were Python instead of Ruby, but at the end of the day that really doesn't matter.
I started with Macports and it never did what I wanted it to. Packages were broken and it required me to do a lot of stuff that I didn't understand. A friend told me that he had recently done all the same installs on Homebrew and it was easy. So I gave Homebrew a try and the exact same packages installed easily and quickly. Homebrew has only gotten easier to use since then.
Maybe I am just not doing anything complicated enough with Homebrew to run into the issues other people have had, but my experience with Homebrew has been a breeze. I really don't have any complaints. I'd maybe prefer if packages were Python instead of Ruby, but at the end of the day that really doesn't matter.
Same. I wrestled with it and Fink for a while. Maybe things have gotten a lot better elsewhere and I have Stockholm Syndrome, but so far so good.
I used MacPorts before Homebrew was a thing, and had plenty of experience with bsd ports going back to the late 90s.
Homebrew was just straight up better, no doubt about it. It wasn't "noobs," "good timing," or "tricky marketing." They were just better, even if still not what these posters desire.
Homebrew was just straight up better, no doubt about it. It wasn't "noobs," "good timing," or "tricky marketing." They were just better, even if still not what these posters desire.
> They were just better
No offense but we are talking about a "package manager" which:
- complained when you installed things in /use/local (where they belong) not managed by itself;
- had a flag to install packages somewhere else which broken half of the packages because they were so poorly written and no one was checking;
- messed with the permission of the file system for no good reason wahtsoever;
- would fail to properly update its own package list if you waited too long because the way they used git was broken beyond belief.
As I never had any of these issues with MacPorts, I might suggest you have a very low ceiling for what you call better. It pains me so much that you have to use Homebrew if you want to have recent packages.
No offense but we are talking about a "package manager" which:
- complained when you installed things in /use/local (where they belong) not managed by itself;
- had a flag to install packages somewhere else which broken half of the packages because they were so poorly written and no one was checking;
- messed with the permission of the file system for no good reason wahtsoever;
- would fail to properly update its own package list if you waited too long because the way they used git was broken beyond belief.
As I never had any of these issues with MacPorts, I might suggest you have a very low ceiling for what you call better. It pains me so much that you have to use Homebrew if you want to have recent packages.
You're imputing far more judgementalness than I intended.
As for better vs worse, let's just say that opinions vary.
As for better vs worse, let's just say that opinions vary.
> But Homebrew wasn't (and isn't) better than MacPorts, either.
Hard disagree. Maybe that situation has improved for MacPorts, but when I made a decision to move from a Thinkpad running FreeBSD to a MBP for work, I gravitated immediately towards MacPorts and found it to be horrendously broken and significantly less friendly than using Ports on FreeBSD. I was expecting a similar UX, and found something that had the trappings of Ports with none of the underlying maintenance that makes it actually work.
Then someone recommended Homebrew. I tried it, and it worked perfectly the first time. I actually kept both on my system for awhile and tried to make MacPorts work, but eventually over the years I gave up on that and I've been a Homebrew user now for more than 5 years. Homebrew is strictly better in the most important factor: It actually works.
Hard disagree. Maybe that situation has improved for MacPorts, but when I made a decision to move from a Thinkpad running FreeBSD to a MBP for work, I gravitated immediately towards MacPorts and found it to be horrendously broken and significantly less friendly than using Ports on FreeBSD. I was expecting a similar UX, and found something that had the trappings of Ports with none of the underlying maintenance that makes it actually work.
Then someone recommended Homebrew. I tried it, and it worked perfectly the first time. I actually kept both on my system for awhile and tried to make MacPorts work, but eventually over the years I gave up on that and I've been a Homebrew user now for more than 5 years. Homebrew is strictly better in the most important factor: It actually works.
For some users I would argue brew was indeed better - I can't judge for the technical level, but definitely so for the UX and troubleshooting.
I might have liked MacPorts with my current experience, but when I first needed to install CLIs and tools I did not have extensive knowledge of shells and paths and such, and MacPorts felt significantly less "integrated" especially when something would fail (as opposed to brew occasionally just asking if you want to overwrite symlinks essentially).
I'll never know if MacPorts was better once you're past the initial hurdles since I'm so used to brew these days, and I believe that sort of experience is probably not isolated. Given the propensity for Mac users to want something that just kinda works and gets details out of the way, I can see why brew succeeded.
I might have liked MacPorts with my current experience, but when I first needed to install CLIs and tools I did not have extensive knowledge of shells and paths and such, and MacPorts felt significantly less "integrated" especially when something would fail (as opposed to brew occasionally just asking if you want to overwrite symlinks essentially).
I'll never know if MacPorts was better once you're past the initial hurdles since I'm so used to brew these days, and I believe that sort of experience is probably not isolated. Given the propensity for Mac users to want something that just kinda works and gets details out of the way, I can see why brew succeeded.
You're probably right about Homebrew feeling more comfortable for new users.
Opinions on Homebrew may diverge with the answers to "How would you prefer to install? a) curl pipe to shell, or b) Download a DMG, double-click to install, and update your PATH." :)
Opinions on Homebrew may diverge with the answers to "How would you prefer to install? a) curl pipe to shell, or b) Download a DMG, double-click to install, and update your PATH." :)
a) curl pipe to shell
b) Download a DMG, double-click to install
These are not morally that different, the DMG installation can also do pretty much whatever, and I doubt people are picking apart the DMG to find the install script to verify that either.
b) Download a DMG, double-click to install
These are not morally that different, the DMG installation can also do pretty much whatever, and I doubt people are picking apart the DMG to find the install script to verify that either.
I'm definitely not resuscitating that old argument here.
Just noting that people have strong opinions about the preferability of either approach.
Just noting that people have strong opinions about the preferability of either approach.
I tried MacPorts. Then I tried brew and stopped using MacPorts. Maybe I just don't use my computer the way you do?
Homebrew "took over" because of a combination of web 2.0 marketing that prematurely shat on its competitors while claiming it was the "modern and beautiful approach" while ignoring hard-learned lessons about the extents to which Apple doesn't care about breaking things and removing programs or libraries from their base system--the Homebrew people were really pissy about "MacPorts insists on installing its own version of X... I already have X!" and would claim "Apple used to chance stuff back six years ago, but they surely stopped by now" and then slowly had to relearn this lesson over time--or supporting binary packages (which both fink and MacPorts had great support for, but the Homebrew people insisted on ignoring that as part of the "I shouldn't have to recompile the world to install software", which was nonsensical) or even basic security mandates (some of which they still haven't fixed, such as the insecure way they handle /usr/local). It was honestly ridiculous, and they only really got to a place of being "better" only by eventually becoming more like the things they insisted were dumb and by capturing all of the new blood contributors mostly due to messaging/marketing (and so eventually ending up in a state where new software now ends up being brought to brew by default). If anything, the only thing I can think of where Homebrew even slightly offered an "advantage" worthy of arguing "this is why they won" is by choosing to dump their stuff in /usr/local instead of making a new root (such as Fink's /sw or Nix's /nix) or carefully next organizing it under /opt (such as was done by MacPorts), which did in fact mean that more software tended to just detect automatically stuff (as some things do their own searches instead of using configured environment variable search paths).
Thanks. It’s nice to see I’m not the only one remembering their arrogant attitude and approach to development, or with these concerns about technical details. It’s unfortunate that Macports became the boring one compared to Homebrew’s new hotness, because Macports is the better design, TCL port files notwithstanding.
+1. i like it but yes if i dont use it everyday and 2 weeks later go to brew install something, omg it has some gigantic update to do before i can brew install anything.
That is frustrating, but fortunately `HOMEBREW_NO_AUTO_UPDATE=1` will take care of it. Then you have to remember to update every now and then yourself, though.
Would you happen to know how to disable upgrading unrelated packages?
I often do `brew upgrade X`. Brew indeed does what is necessary to upgrade package X + deps. But then goes on and starts upgrading unrelated packages.
I often do `brew upgrade X`. Brew indeed does what is necessary to upgrade package X + deps. But then goes on and starts upgrading unrelated packages.
Brew does not start randomly upgrading unrelated packages.
Packages have dependencies, and those dependencies have dependencies. Try `brew deps ---tree x` to see all the dependencies for you package.
Look at `brew pin` to pin packages you don't want brew to upgrade.
Many formula are versioned. For example if you install `postgresql` it will do major upgrades of postgres as they become available, but if you install `[email protected]` it will only install updates to 9.6.
Packages have dependencies, and those dependencies have dependencies. Try `brew deps ---tree x` to see all the dependencies for you package.
Look at `brew pin` to pin packages you don't want brew to upgrade.
Many formula are versioned. For example if you install `postgresql` it will do major upgrades of postgres as they become available, but if you install `[email protected]` it will only install updates to 9.6.
so, you don't do a 'yum update' before installing software on your system (or 'apt-get update' or whatever)? Are you also the type of person that refuses to update system software because "it takes too long, and I'm too busy"?
No, I don’t like forced 5 minute stops to my work.
Yes, I’m the type of person who only updates on my schedule when notified, or when I need something.
These little tools installed by home brew aren’t just little tools, they’re dependencies for whatever else they’re used in. The fact that I need package “X” doesn’t mean I want package Y, something entirely unrelated, updated without my consent.
It’s MY fucking computer. Let ME decide what software gets installed on it and when.
Yes, I’m the type of person who only updates on my schedule when notified, or when I need something.
These little tools installed by home brew aren’t just little tools, they’re dependencies for whatever else they’re used in. The fact that I need package “X” doesn’t mean I want package Y, something entirely unrelated, updated without my consent.
It’s MY fucking computer. Let ME decide what software gets installed on it and when.
Not GP, but I do it quite often, but not every single time. Also yum/apt/etc updates are way faster and much more responsive than brew.
I generally don't do an apt update before installing a package that I needed at that moment.
However I do full update / upgrades when it is convenient for me.
That's the point.
However I do full update / upgrades when it is convenient for me.
That's the point.
I have the same issue and for me there is a simple difference:
I probably use homebrew for a handfull of tools, in debian etc. my packagetmanager manages everything.
Its not a huge issue but the thought of 'ah shit i need to run update' comes with 'that will be slow'
I probably use homebrew for a handfull of tools, in debian etc. my packagetmanager manages everything.
Its not a huge issue but the thought of 'ah shit i need to run update' comes with 'that will be slow'
When I get angry about brew sucks I always remind myself there is npm.
The usual non-productive rant.
What prevents you to do it better then? What prevent you from forking it? Sharing improvement ideas? Contributing to the project?
"It sucks" doesn't help anyone understand your frustrations and does not serve the message you're trying to share (let this one be valid or not).
Also, as everything that is open-source/free: if you hate it, don't use it, that's it. And let the people who appreciate it be productive and build awesome tools with it.
What prevents you to do it better then? What prevent you from forking it? Sharing improvement ideas? Contributing to the project?
"It sucks" doesn't help anyone understand your frustrations and does not serve the message you're trying to share (let this one be valid or not).
Also, as everything that is open-source/free: if you hate it, don't use it, that's it. And let the people who appreciate it be productive and build awesome tools with it.
Not parent, and I'm not going to say it sucks, the project takes a lot of work from a lot of people and I ain't the one pissing on other people's work, it definitely could use some improvements syntax wise though,
What was it, brew install? Brew cask? Oh , now is brew cask install... or was it brew install --cask?
I get the analogy, but being a package manager, but was it really that bad to use 'brew install', 'brew update', and 'brew upgrade' for everything?
And it's true that it is a little frustrating at times when you don't use it for a while, you 'brew install xx' and wait 4 minutes until "Updating homebrew" finished with its dozens loops between shells, ruby etc doing its stuff (which I assume is refetching repos, but couldn't know it from the output)
I use it because it's the most common thing for mac, but I miss APT and DNF everytime I use it, not going to lie
I get the analogy, but being a package manager, but was it really that bad to use 'brew install', 'brew update', and 'brew upgrade' for everything?
And it's true that it is a little frustrating at times when you don't use it for a while, you 'brew install xx' and wait 4 minutes until "Updating homebrew" finished with its dozens loops between shells, ruby etc doing its stuff (which I assume is refetching repos, but couldn't know it from the output)
I use it because it's the most common thing for mac, but I miss APT and DNF everytime I use it, not going to lie
> I get the analogy, but being a package manager, but was it really that bad to use 'brew install', 'brew update', and 'brew upgrade' for everything?
That’s how it works now. You only need `--cask` for (rare) disambiguations.
Homebrew Cask started as a different project (casks and formulae are still inherently different), so not having `brew cask` only became viable after the two projects merged.
> it is a little frustrating at times when you don't use it for a while, you 'brew install xx' and wait 4 minutes until "Updating homebrew" finished
Use `HOMEBREW_NO_AUTO_UPDATE=1`. Just don’t open an issue if something breaks and you didn’t update beforehand.
> which I assume is refetching repos, but couldn't know it from the output
`--verbose`.
That’s how it works now. You only need `--cask` for (rare) disambiguations.
Homebrew Cask started as a different project (casks and formulae are still inherently different), so not having `brew cask` only became viable after the two projects merged.
> it is a little frustrating at times when you don't use it for a while, you 'brew install xx' and wait 4 minutes until "Updating homebrew" finished
Use `HOMEBREW_NO_AUTO_UPDATE=1`. Just don’t open an issue if something breaks and you didn’t update beforehand.
> which I assume is refetching repos, but couldn't know it from the output
`--verbose`.
Homebrew (and CocoaPods, perhaps famously) uses github as a CDN for their package listings, syncing the git repos likely takes the most time here
Do you mean apt or apt-get or apt-get install or was it apt-install --get?
even on old infrastructure its already apt and nothing else anymore. So they advanced.
No, it's really not. apt-get works just fine on my current Ubuntu instances.
> What prevents you to do it better then? What prevent you from forking it? Sharing improvement ideas? Contributing to the project?
I think ~everything he stated is generally assumed true. I use Brew installed software every single day, and appreciate it. That doesn't put it above criticism though.
I think ~everything he stated is generally assumed true. I use Brew installed software every single day, and appreciate it. That doesn't put it above criticism though.
"brew fucking sucks" is just whining, not reasonable criticism IMHO
There is no criticism in their statement though, just a generalized opinion/rant that doesn't point out single issue and is factually inaccurate.
> doesn't point out single issue
> is factually inaccurate.
I think these two might be somewhat contradictory.
I think these two might be somewhat contradictory.
I don't, he said someone else would have filled the void, there was no void considering this project came after macports and fink
> What prevents you to do it better then?
The mindshare of nearly the entire community that develops software for the Mac. Homebrew, the tool, is inferior to several other options, but developers of software treat it as the one true package manager on Mac. It's so frustrating to see projects offer it as the only supported way to install their software on Mac apart from building it from source.
Your question reads like "What prevents you from building a better social network than Facebook?" response to criticisms of that platform. And the answer is that in a tool like Facebook or Homebrew, all the value is in the ecosystem. Building a better tool is useless until everyone is using it. And no one will use it until everyone else is using it. It's a classic network effect, and it inhibits viable competition.
The mindshare of nearly the entire community that develops software for the Mac. Homebrew, the tool, is inferior to several other options, but developers of software treat it as the one true package manager on Mac. It's so frustrating to see projects offer it as the only supported way to install their software on Mac apart from building it from source.
Your question reads like "What prevents you from building a better social network than Facebook?" response to criticisms of that platform. And the answer is that in a tool like Facebook or Homebrew, all the value is in the ecosystem. Building a better tool is useless until everyone is using it. And no one will use it until everyone else is using it. It's a classic network effect, and it inhibits viable competition.
I think the big difference is that Homebrew, unlike Facebook, is open-source (and doesn't have a huge trove of data to protect, leading them to go after third-party clients).
It's plausible that you could just write a front-end that keeps using the same remote package repository, that fixes everything you complain about.
I suppose it depends on what exactly your complaints are, but most of the complaints here (CLI, auto-update, etc) seem like they could be addressed with just a client fork.
It's plausible that you could just write a front-end that keeps using the same remote package repository, that fixes everything you complain about.
I suppose it depends on what exactly your complaints are, but most of the complaints here (CLI, auto-update, etc) seem like they could be addressed with just a client fork.
> What prevents you to do it better then? What prevent you from forking it? Sharing improvement ideas? Contributing to the project?
Time?
> Also, as everything that is open-source/free: if you hate it, don't use it, that's it. And let the people who appreciate it be productive and build awesome tools with it.
This is such an unhealthy attitude. Just because something is free doesn't make it above criticism. Also doesn't mean that the maintainers don't benefit from their projects even if there isn't direct compensation (more career opportunities, visibility, etc.) This idea that we need to walk on eggshells around anyone that does any volunteer work is kinda absurd.
Time?
> Also, as everything that is open-source/free: if you hate it, don't use it, that's it. And let the people who appreciate it be productive and build awesome tools with it.
This is such an unhealthy attitude. Just because something is free doesn't make it above criticism. Also doesn't mean that the maintainers don't benefit from their projects even if there isn't direct compensation (more career opportunities, visibility, etc.) This idea that we need to walk on eggshells around anyone that does any volunteer work is kinda absurd.
> Just because something is free doesn’t make it above criticism.
What was being responded to wasn’t criticism. It was whining without any substance.
What was being responded to wasn’t criticism. It was whining without any substance.
[deleted]
> I hate that brew is good enough that it’s got some kind of local maximum such that there’s no replacement forthcoming.
You may be interested in trying out nix for package management [1], or even for configurations and providing development environments (see my other comment [2]).
[1]: https://builtwithnix.org/
[2]: https://news.ycombinator.com/item?id=26038614
You may be interested in trying out nix for package management [1], or even for configurations and providing development environments (see my other comment [2]).
[1]: https://builtwithnix.org/
[2]: https://news.ycombinator.com/item?id=26038614
When I tried nix on my mac a while back, it took forever to install basic things, had very verbose logs, was far more complicated and was missing packages. Is it still like that?
Nix on macos only got a pre-built binary cache a couple of years ago - before that, yes, almost everything had to be built from the ground up.
Not my experience at all.
MacPorts meanwhile existed years before Homebrew, and is alive and well.
Mate, can you tone it down a little? Your opinion is fine but it’s unnecessarily inflammatory towards basically volunteer work.
Besides the already-mentioned MacPorts, NetBSD's pkgsrc is multi-platform, including macOS (AFAICT):
* https://www.pkgsrc.org/
* https://www.pkgsrc.org/
macOS users may want to use my binary package repository, updated every few days from pkgsrc trunk:
https://pkgsrc.joyent.com/install-on-osx/
https://pkgsrc.joyent.com/install-on-osx/
Yeah, it works on macOS and is actually very nice, but its package catalog is not quite as comprehensive and OS upgrades are a huge headache. In other words, a solid alternative with a different set of issues.
It’s hard to disprove this but IMO brew is the best package manager I’ve used (at least out of any of the widely used ones). I’m sure there is a better way to do things but given other common package managers that I find to be much worse, I’d argue it’s equally (if not more) likely that the alternative to homebrew would be worse.
[deleted]
export HOMEBREW_NO_AUTO_UPDATE=1That doesn't solve the evergreen packages problem, and I'm tired of people trotting out this flag when people (rightfully in my opinion) complain about brew upgrading literally everything it can get its hands on.
What do you mean by random unwanted updates? As far as I know, the only way to update is by running brew upgrade.
To codify both replies to yours as an outsider who watches macOS coworkers struggle: brew is akin to running Arch, where the concept is latest-tagged-release of any given software.
The newest version of X introduces a feature which has a need of Y library (dependency) >= n+1, where n is your already installed version. It just so happens that Y is shared between 3 applications; so if you upgrade Y to satisfy X, you now have to recompile/upgrade (depending on details) A, B and C as well to use the newly updated version of Y.
Arch (and other rolling releases) do/does this every day, it's just that the work is offloaded to upstream packagers. Brew is more "AUR-like" where it's all down downstream on your own system, so you get to deal with the work and churn through the recompiles yourself.
The newest version of X introduces a feature which has a need of Y library (dependency) >= n+1, where n is your already installed version. It just so happens that Y is shared between 3 applications; so if you upgrade Y to satisfy X, you now have to recompile/upgrade (depending on details) A, B and C as well to use the newly updated version of Y.
Arch (and other rolling releases) do/does this every day, it's just that the work is offloaded to upstream packagers. Brew is more "AUR-like" where it's all down downstream on your own system, so you get to deal with the work and churn through the recompiles yourself.
> Brew is more "AUR-like" where it's all down downstream on your own system, so you get to deal with the work and churn through the recompiles yourself.
I don’t see how Homebrew would be similar to AUR.
Unlike AUR contributors, Homebrew maintainers curate the packages, test them, monitor upstream projects for updates, build and upload binary packages and do their best to support users when anything breaks.
Anytime a Homebrew user installs a formula from homebrew-core and the system starts to (re-)compile, almost certainly something is wrong.
I don’t see how Homebrew would be similar to AUR.
Unlike AUR contributors, Homebrew maintainers curate the packages, test them, monitor upstream projects for updates, build and upload binary packages and do their best to support users when anything breaks.
Anytime a Homebrew user installs a formula from homebrew-core and the system starts to (re-)compile, almost certainly something is wrong.
It depends on the formula, designs and maintainers of them - we run an internal tap and some items are casks, some are bottles and some are compile as you go. It just depends on what that widget is and does, and in some cases there are tools which are broken on latest-tagged releases and people have to pin older versions or using git HEAD for (some period of time) until the tagged released is fixed upstream. (we're looking at you, sshuttle-who-deprecated-remote-python2-in-v1.0-thru-1.0.4-and-broke-lots-of-workflows-with-jumphosts)
For some time now, in the default configuration, `brew upgrade` is run automatically any time you run `brew install`. You have to set HOMEBREW_NO_AUTO_UPDATE to disable this behavior.
EDIT: whoops, that was incorrect. It's actually `brew update` that is run automatically, which updates Homebrew itself plus all of its formulae. However, I think often the effect can't be similar. If formulae are updated, and the new package you're trying to install shares a dependency with other packages, the dependency will be automatically updated as part of the install process. I'm not sure if this can also trigger an update of an existing leaf package though.
EDIT: whoops, that was incorrect. It's actually `brew update` that is run automatically, which updates Homebrew itself plus all of its formulae. However, I think often the effect can't be similar. If formulae are updated, and the new package you're trying to install shares a dependency with other packages, the dependency will be automatically updated as part of the install process. I'm not sure if this can also trigger an update of an existing leaf package though.
Yes, figuring this out I created an alias a few months ago. #LifeImproved :D
Add this to your .zshrc or equivalent (f for fast):
alias brewf="HOMEBREW_NO_AUTO_UPDATE=1 brew"
Add this to your .zshrc or equivalent (f for fast):
alias brewf="HOMEBREW_NO_AUTO_UPDATE=1 brew"
Personally; only issue i tend to have is that when I install X, it breaks Y forcing reinstallation of ~everything. What should be a small install ends up taking 30m of cleanup.
Entirely likely it's user error on my part; but also problem I haven't really had with other 'nix package managers.
Entirely likely it's user error on my part; but also problem I haven't really had with other 'nix package managers.
Which isn't funny when Y is Postgres and your database is no longer readable post-upgrade. Happened to me.
[deleted]
one time i ran “brew upgrade ffmpeg” which somehow forced a major version bump of postgres.
I installed awscli and somehow emacs ended up installed in my system.
[deleted]
Macports? They’ve been around even longer than brew. But they were always a bit too Linuxy for most Mac users.
I always thought that brew was the "Linuxy" one and Macports was FreeBSD Ports for the Mac.
Jordan Hubbard was involved in the creation of both FreeBSD Ports and MacPorts (DarwinPort), so it makes sense that it shares the BSD ways of doing things. His decision to use Tcl for MacPorts also came from his experience dealing with Makefiles[1]
[1]: https://netbsd.org/gallery/10years.html#hubbard
[1]: https://netbsd.org/gallery/10years.html#hubbard
Well I don't mean Linuxy in the architecture sense but Linuxy in the preparation and final stage installation sense. Like Homebrew does not need elevated privileges to work and actively discourages it. MacPorts, when something breaks, is a rabbit hole of elevated commands to bring it back to functional.
Of course this is my opinion as I had Macports and Homebrew installed on my MBP 2012. I've swapped to a newer MBP and I only have HB installed. Since most packages are on HB I no longer need to have both installed.
Of course this is my opinion as I had Macports and Homebrew installed on my MBP 2012. I've swapped to a newer MBP and I only have HB installed. Since most packages are on HB I no longer need to have both installed.
> Like Homebrew does not need elevated privileges to work and actively discourages it
It does this by chowning /usr/local to a local user, which is worse for security than running sudo because now any malicious process can overwrite /usr/local/bin/bash without asking for privileges. macOS having /usr/local/bin in its $PATH by default also doesn't help. Homebrew made this security vs usability tradeoff because most Mac users are a single user, which makes sense in its context.
The recent change of moving Homebrew to /opt/homebrew (at least for M1 Mac) is a better solution for this as it is no longer in the default $PATH. On the other hand, MacPorts approach of requiring sudo allows it to drop privileges to other unprivileged non-admin user (macports) during build in addition to building everything via sandbox-exec.
It does this by chowning /usr/local to a local user, which is worse for security than running sudo because now any malicious process can overwrite /usr/local/bin/bash without asking for privileges. macOS having /usr/local/bin in its $PATH by default also doesn't help. Homebrew made this security vs usability tradeoff because most Mac users are a single user, which makes sense in its context.
The recent change of moving Homebrew to /opt/homebrew (at least for M1 Mac) is a better solution for this as it is no longer in the default $PATH. On the other hand, MacPorts approach of requiring sudo allows it to drop privileges to other unprivileged non-admin user (macports) during build in addition to building everything via sandbox-exec.
Running untrusted software on these sort of systems is fundamentally broken, no matter what the package manager chooses chown or not chown. A malicious program could edit ~/.bashrc to modify the user's PATH, or wrap sudo with a keylogger then use that password to chown anything it likes. That's not even a theoretical but unlikely sort of attack; it's quite trivial.
> alias sudo='echo not what I expected'
> sudo foo
not what I expectedThat's fair, but it's only affecting single user, while writable /usr/local affects all users. However most Mac users are single user, so the tradeoff makes sense in this context.
Linux? Macports take direct inspiration from FreeBSD ports
This seems like a rather exceptional, unsubstantiated, and mean spirited take. I've run into some strange issues with brew over the years, but compared to npm and apt it's been far less prone to causing me headaches.
I rage quit Homebrew to MacPorts. No complain after 2 years. Not a single bug. Installation are much faster than 10 years ago too (macports use pre-compiled binaries now). Give it a try if you have some time to lose.
I agree with you wholeheartedly. Homebrew was my least favorite part of the MacOS experience, which is a shame since it was basically the most important piece of software I had installed on that thing.
It might not cover everything, but it also has a superset of other things more - conda + conda-forge (with mamba too for better performance)
The had also apple silicon support for many things more than a month ago.
The had also apple silicon support for many things more than a month ago.
[deleted]
brew is an amazing achievement. It doesn't do random unwanted updates at odd times. It doesn't do anything at all unless you run run it. And it tells you want it will do beforehand. Nobody would have "filled the void" - building software isn't a zero sum game. If someone had something better they would have continued to work on it and it would have "taken over". There, I said it.
That is incorrect. Brew will do random upgrades when running `brew install` unless you set the non-default `HOMEBREW_NO_AUTO_UPDATE=1` [1] so every now and then when you brew install something it will e.g. upgrade the python binary from 3.x => 3.(x+1) and break all virtualenvs using symlinks.
Python is just one example, I've spend countless time fixing random broken packages due to the unpredictability of `brew install`.
[1] https://github.com/Homebrew/brew/issues/1670
[1] https://github.com/Homebrew/brew/issues/1670
This is just a misunderstanding of how brew works. Brew is doing what it is designed to do. Your assumptions are that brew should be able to "pin" a package to an exact version, or that it is selecting packages at random to upgrade, but those assumptions are wrong.
https://docs.brew.sh/FAQ#why-does-brew-upgrade-formula-also-...
However brew does support your use case, but it take some extra effort. If you want to use brew to install an exact version of python you need to create a tap: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap
Also, you aren't forced to use brew to install that version of python. You can do so yourself using the standard make; make install. It would be best to install it under /opt. Or use any other available method of installing software on your mac.
https://docs.brew.sh/FAQ#why-does-brew-upgrade-formula-also-...
However brew does support your use case, but it take some extra effort. If you want to use brew to install an exact version of python you need to create a tap: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap
Also, you aren't forced to use brew to install that version of python. You can do so yourself using the standard make; make install. It would be best to install it under /opt. Or use any other available method of installing software on your mac.
[deleted]
If you've used Valet, you know truly that Brew is the worst.
I am cool with constructive criticism, but you do realize brew is free, right?
If you are not happy with open source, you have a couple of options:
- build your own brew
- brew is open source, so you can make contributions to improve
- pay for something like brew (though probably not an option for brew)
Have you done any of the above before complaining? I am guessing - no. Otherwise, say "thank you" and move on, my friend.
If you are not happy with open source, you have a couple of options:
- build your own brew
- brew is open source, so you can make contributions to improve
- pay for something like brew (though probably not an option for brew)
Have you done any of the above before complaining? I am guessing - no. Otherwise, say "thank you" and move on, my friend.
I get where you're coming from, but I think the open source community benefits from being, well, open. Walling yourself off from user frustrations and criticism with the attitude that they are ungrateful is not how projects evolve to better meet user needs.
Being free doesn't absolve it of criticism.
You sure sound absolutely cool with criticism.
> There, I said it.
What a waste of bytes and bandwidth. "[homebrew] It’s the worst package manager I’ve used" is true for all users that have only used one package manager. The opposite claim ("it's the best I've used") would simultaneously be true.
You could at least have mentioned _why_ and that could have kickstarted a meaningful discussion, but instead your comment is the equivalent on a thumbs down in a youtube video.
What a waste of bytes and bandwidth. "[homebrew] It’s the worst package manager I’ve used" is true for all users that have only used one package manager. The opposite claim ("it's the best I've used") would simultaneously be true.
You could at least have mentioned _why_ and that could have kickstarted a meaningful discussion, but instead your comment is the equivalent on a thumbs down in a youtube video.
Pot, meet kettle:
https://news.ycombinator.com/item?id=26037357
> volta83 1 hour ago | parent [–] | on: Homebrew 3.0
> I used MacPorts before hombrew. Homebrew "just worked", MacPorts sucked.
> Maybe I was too dumb to use MacPorts, but all other MacPort used I knew back then all moved to homebrew very quickly.
> reply
https://news.ycombinator.com/item?id=26037357
> volta83 1 hour ago | parent [–] | on: Homebrew 3.0
> I used MacPorts before hombrew. Homebrew "just worked", MacPorts sucked.
> Maybe I was too dumb to use MacPorts, but all other MacPort used I knew back then all moved to homebrew very quickly.
> reply
It’s Weird that Apple doesn’t do this themselves. It’s not like they don’t have a cash. And it’s important for devs to have up to date tooling.
This intrepid band of volunteers are adding huge value to one of the largest corporations on earth. I appreciate the DIY effort of anyone who volunteers, though I see the donate tab on their website and sigh a little.
This intrepid band of volunteers are adding huge value to one of the largest corporations on earth. I appreciate the DIY effort of anyone who volunteers, though I see the donate tab on their website and sigh a little.
> It’s Weird that Apple doesn’t do this themselves. It’s not like they don’t have a cash.
I can understand them not wanting to do it themselves. I don't think they want to take on the responsibility for maintaining all those packages (for legal reasons or otherwise). Because it's a "not officially Apple" thing, Homebrew can probably get away with a "no warranty" sticker that an official Apple project couldn't.
What Apple should do, however, is ship a DUMP TRUCK OF MONEY to every Homebrew maintainer on a regular basis. That project is crucial to basically every Apple developer, and it massively enriches macOS as a general purpose development platform. Apple would be fools to not support it financially.
I can understand them not wanting to do it themselves. I don't think they want to take on the responsibility for maintaining all those packages (for legal reasons or otherwise). Because it's a "not officially Apple" thing, Homebrew can probably get away with a "no warranty" sticker that an official Apple project couldn't.
What Apple should do, however, is ship a DUMP TRUCK OF MONEY to every Homebrew maintainer on a regular basis. That project is crucial to basically every Apple developer, and it massively enriches macOS as a general purpose development platform. Apple would be fools to not support it financially.
Apple did help with implementing support for ARM CPUs as mentioned in the changelog: "Particular thanks on Homebrew 3.0.0 go to MacStadium and Apple for providing us with a lot of Apple Silicon hardware and Cassidy from Apple for helping us in many ways with this migration." Making sure Homebrew works on ARM Mac devices made sense for Apple.
Meanwhile providing money for no reason to Homebrew wouldn't make business sense. As far Apple is concerned, Homebrew works, and providing financial support wouldn't make it work better.
Meanwhile providing money for no reason to Homebrew wouldn't make business sense. As far Apple is concerned, Homebrew works, and providing financial support wouldn't make it work better.
Might provide stability by making it less likely for key maintainers to walk away because they don't have time for both homebrew and their day job.
>Meanwhile providing money for no reason to Homebrew
>wouldn't make business sense. As far Apple is concerned,
>Homebrew works, and providing financial support wouldn't
>make it work better.
Well, I think that funding really smart people running really valuable projects tend to make them even more valuable.
Besides, there's some cosmic Karmic justice if this happens.
>wouldn't make business sense. As far Apple is concerned,
>Homebrew works, and providing financial support wouldn't
>make it work better.
Well, I think that funding really smart people running really valuable projects tend to make them even more valuable.
Besides, there's some cosmic Karmic justice if this happens.
JeremyBanks(1)
Apple needs to dump a truck of money on their own developer tooling team and double every team size. If you knew how small they were you would be surprised!
Xcode / swifts build speed is still pretty bad, xcode still chokes on large projects, codesign is an eternal flaky nightmare, they still don't have first class command line support for many things, they don't have network indexing & build caching like bazel does, it's worse than android for maintaining a device lab for testing (adb vs... `instruments` kind of) and on and on it goes.
Xcode / swifts build speed is still pretty bad, xcode still chokes on large projects, codesign is an eternal flaky nightmare, they still don't have first class command line support for many things, they don't have network indexing & build caching like bazel does, it's worse than android for maintaining a device lab for testing (adb vs... `instruments` kind of) and on and on it goes.
> Apple would be fools to not support it financially.
Since people are already doing an excellent job for free, why would they start paying them? Clearly the lack of Apple funding has not hurt the project thus far.
Since people are already doing an excellent job for free, why would they start paying them? Clearly the lack of Apple funding has not hurt the project thus far.
I mean, I don't run any billion dollar companies, so what do I know, but Apple donating a couple of million to ensure that Homebrew stays active seems like a no-brainer investment to me.
Yeah, Homebrew has been doing this work for free thus far, but open source projects die all the time. It's very much in Apple's interest to ensure this one doesn't.
Yeah, Homebrew has been doing this work for free thus far, but open source projects die all the time. It's very much in Apple's interest to ensure this one doesn't.
Side note: Apple has been a trillion-dollar company since 2018. https://en.wikipedia.org/wiki/List_of_public_corporations_by...
Microsoft is investing a ton of money in developer productivity for non-traditional Windows developers. Apple has had a mindshare lead there but it’s not a permanent situation and a tiny fraction of their cash on hand is much cheaper than trying to win people back.
One could say Homebrew is successful despite Apple not trying to even mention their name, even less help them be successful. Many groups also look at successful groups and think "How can we make them more successful?" but don't think that's in Apples DNA.
Apple has mentioned Homebrew; a screenshot of it is the banner on their Twitter account.
I don't know about the "DUMP TRUCK OF MONEY", but a program that formalizes support for the Open Source community on MacOS would be a win for Apple as well as Apple's customers.
Potato, potahto :)
IIRC, Apple does (or at least did) donate Hardware to some of the maintainers. I remember some of the Homebrew maintainers answering in comments here on HN that hey received M1-based MacMinis - this is of course in the interest of Apple but also shows that they do care about it.
As I mentioned in another comment, Apple supports them with hardware and technical resources. Seeing what happened with the whole CentOS mess, I am kind of glad that homebrew remains independent and can continue to do so without relying on Apple’s money.
Yeah, the app store has become a source of a lot of controversy around policies, so signing up for more public criticism of how they handle a package manager is probably a headache they don't need.
> I don't think they want to take on the responsibility for maintaining all those packages
That's not how a package manager works. The people responsible for APT/AUR do not maintain all the packages within the repositories themselves. This even applies to the App Store. Apple does not maintain the apps there themselves, it's up to the people publishing the apps. So there really isn't any reasons except they can't make money on it, hence it doesn't exist as an officially sanctioned way of pulling down programs.
That's not how a package manager works. The people responsible for APT/AUR do not maintain all the packages within the repositories themselves. This even applies to the App Store. Apple does not maintain the apps there themselves, it's up to the people publishing the apps. So there really isn't any reasons except they can't make money on it, hence it doesn't exist as an officially sanctioned way of pulling down programs.
Yes and no, Apple doesn't want the support issues going into their queue and clogging up their customer support system.
When Billy Bob installs the wrong package from Homebrew now he just complains on a forum like this, or on stack overflow. He doesn't email Apple
When Billy Bob installs the wrong package from Homebrew now he just complains on a forum like this, or on stack overflow. He doesn't email Apple
Yeah, if Apple says "This is our official package manager, and you can use it to install OpenSSL/nginx/whatever", like or not, they are on the hook if it breaks, and they have to fix it. Like, companies are going to be like "we trusted you and now our website is broken, and we're going to sue you".
Homebrew gets away with this a little bit by basically being unofficial, implicitly saying "we're not guaranteeing anything here, this is purely for convenience". It would be much harder to make this argument if you were an official Apple project.
Homebrew gets away with this a little bit by basically being unofficial, implicitly saying "we're not guaranteeing anything here, this is purely for convenience". It would be much harder to make this argument if you were an official Apple project.
https://en.wikipedia.org/wiki/MacPorts (nee DarwinPorts) was started with the involvement/sponsorship of Apple and was probably the most popular Mac OS X package manager / port library around the mid-00s.
In the case of Swift, they actually took this advice to heart - and hired Max to help them do it.
That said, it remains disappointing to me that unless you're producing content with Apple's hardware or building apps for the Stores, they don't really do much to help you.
For example, if you're writing client or server-side web code, they will acknowledge your existence, and are more than willing to sell you a Mac, but that's about it.
^ This doesn't even get into the concerns around all of the supporting pieces that go along with this code - e.g, documentation, training materials, and outreach - the tooling for this part of the process is voluminous in its own right.
https://en.wikipedia.org/wiki/Comparison_of_documentation_ge...
That said, it remains disappointing to me that unless you're producing content with Apple's hardware or building apps for the Stores, they don't really do much to help you.
For example, if you're writing client or server-side web code, they will acknowledge your existence, and are more than willing to sell you a Mac, but that's about it.
^ This doesn't even get into the concerns around all of the supporting pieces that go along with this code - e.g, documentation, training materials, and outreach - the tooling for this part of the process is voluminous in its own right.
https://en.wikipedia.org/wiki/Comparison_of_documentation_ge...
[deleted]
I don't think it's weird. Actually I think it's important to keep this as a community effort, in the spirit of FOSS. From developers, to developers, you know. Surely it would be nice for the maintainers if Apple could throw in some cash, though :)
Apple did sort of half-officially supported MacPorts, precursor of Brew.
Nowadays they don’t want to touch anything GPL so that might be it
Nowadays they don’t want to touch anything GPL so that might be it
It’s Weird that Apple doesn’t do this themselves.
If Apple did it, HN would be awash in "Walled garden!" and "Monopoly!" hysteria.
If Apple did it, HN would be awash in "Walled garden!" and "Monopoly!" hysteria.
It saddens me as I see this massive infusion of developer time and energy being donated to one of the biggest tech companies around. If that effort had instead gone into making Linux better, which Homebrew obviously builds on, where would Linux workstations be now? Would I get a nice Linux laptop from my company instead of being forced to use a MacBook?
Contributing to Linux also helps the biggest tech companies around - namely IBM and Oracle amongst a host of others. When you contribute to free and open source software you should know and understand you're providing your labor for free to tech behemoths. For most it's a labor of love and aligns with their passion and so everything is cool but you run across a few who's feelings get hurt and feel like they're getting ripped-off.
Contributing specifically to the desktop experience of Linux is another matter (unless maybe you're a GNOME developer.)
Well if you donate code to linux anyone can use your donation for free. It helps everyone not one specific hardware vendor. (unless your donating drivers...)
It seems to me that if you compare Apple and Microsoft, it's only the latter that cares deeply about the developer experience on their platform.
https://github.com/microsoft/winget-cli
https://github.com/microsoft/winget-cli
It's really weird adjusting to a post-Ballmer Microsoft. I have plenty of existing loathing for that company from their behavior towards Netscape and Linux in the 90s and early 2000s (among other, smaller players). However, their developer-focused offerings are amazing, now that they made .NET Core open. C# is great to work with.
Meanwhile, Apple is now engaging in anticompetitive behavior that I find frustrating. (App Store stuff.) Things have turned on their head.
Meanwhile, Apple is now engaging in anticompetitive behavior that I find frustrating. (App Store stuff.) Things have turned on their head.
That's been mostly true since both of the company's founding (Microsoft in 1975 and Apple's in 1976). What was Microsoft's first product? Basic. Microsoft's Basic ran on the most popular home computer platforms of the day (except Apple's). Even Commodore's Basic was fully interoperable with Microsoft's.
What was Apple's first product? A computer. A computer meant for people not having a CS background. The Apple II kicked off the home computing revolution, i.e. bringing computing to the masses. The Mac was the computer "for the rest of us" and was aimed squarely at graphic artists, desktop publishers, musicians, and the like.
So yes, Microsoft has always been developer and business focused whereas Apple has always been the computer "for the rest of us."
What was Apple's first product? A computer. A computer meant for people not having a CS background. The Apple II kicked off the home computing revolution, i.e. bringing computing to the masses. The Mac was the computer "for the rest of us" and was aimed squarely at graphic artists, desktop publishers, musicians, and the like.
So yes, Microsoft has always been developer and business focused whereas Apple has always been the computer "for the rest of us."
Pedantically, while it's true that the Apple II originally shipped with Steve Wozniak's Integer BASIC interpreter, a Microsoft BASIC implementation, Applesoft BASIC, was licensed soon after the II's release and replaced Integer BASIC in ROM on the II+ and all future models.
Also, to be fair to "graphic artists ... and the like", one of the reasons the Mac platform remained popular among graphics arts professionals through the '90s was that system-level inter-application scripting, added to the platform in 1993, was well-supported by both Apple and third-party application vendors, whereas analogous cross-application scripting in Windows was mostly limited to Microsoft Office products.
Also, to be fair to "graphic artists ... and the like", one of the reasons the Mac platform remained popular among graphics arts professionals through the '90s was that system-level inter-application scripting, added to the platform in 1993, was well-supported by both Apple and third-party application vendors, whereas analogous cross-application scripting in Windows was mostly limited to Microsoft Office products.
It's a shame that the windows experience is so poor that it negates any positives introduced by the developer experience improvements.
Apple is not a good steward of open source projects. We saw what happened with CUPS. Apple took it over and it basically died.
[deleted]
Too much of the tooling that people want to use is GPL.
Apple is more allergic to the GPL than any other company on Earth. They would never do something official that would even put GPL software in their orbit.
Apple is more allergic to the GPL than any other company on Earth. They would never do something official that would even put GPL software in their orbit.
If someone is doing it for free, why step up and spend money on it? /s
For sure Apple employees are using lots of homebrew every day :)
For sure Apple employees are using lots of homebrew every day :)
> It’s Weird that Apple doesn’t do this themselves. It’s not like they don’t have a cash. And it’s important for devs to have up to date tooling.
There is no money to get from it. And developers are not the "end user" for Apple anymore. I don't see why Apple should even care about Homebrew.
There is no money to get from it. And developers are not the "end user" for Apple anymore. I don't see why Apple should even care about Homebrew.
Not directly, but developers provide Apple with billions of dollars in value every year.
I use nixpkgs and home-manager for a consistent package management and configuration across MacOS and Linux (NixOS), which others also reported great success [1]. As noted in the article [1], home-manager has a steeper learning curve, but is much more powerful (e.g., supports providing development dependencies and environment, or even extend to Ops).
For the interested, search for some variants of “homebrew home-manager nix”, and you may find lots of resources [2][3][4].
[1]: https://lucperkins.dev/blog/home-manager/
[2]: https://www.softinio.com/post/moving-from-homebrew-to-nix-pa...
[3]: https://wickedchicken.github.io/post/macos-nix-setup/
[4]: https://dev.to/louy2/use-nix-on-macos-as-a-homebrew-user-22d
For the interested, search for some variants of “homebrew home-manager nix”, and you may find lots of resources [2][3][4].
[1]: https://lucperkins.dev/blog/home-manager/
[2]: https://www.softinio.com/post/moving-from-homebrew-to-nix-pa...
[3]: https://wickedchicken.github.io/post/macos-nix-setup/
[4]: https://dev.to/louy2/use-nix-on-macos-as-a-homebrew-user-22d
I started using Home Manager long after I adopted Nix. I must say, I should’ve used it far more earlier on. With the power of the Nix language, Home Manager gives me so much more control and customizability over packages that just can’t be provided with traditional package managers.
While it takes some learning to leverage the full capability of Home manager, it’s also easy to get started. People new to Nix can start out with a basic configuration specifying a list of packages to install and then gradually move to a more capable configuration as they learn more.
While it takes some learning to leverage the full capability of Home manager, it’s also easy to get started. People new to Nix can start out with a basic configuration specifying a list of packages to install and then gradually move to a more capable configuration as they learn more.
Was it him who was turned down by Apple and Google, after he built homebrew...?
Yes, he posted more information in an answer on Quora[1] to clarify why he felt he was turned down.
[1]: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
[1]: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
> But ultimately, should Google have hired me? Yes, absolutely yes. I am often a dick, I am often difficult, I often don’t know computer science, but. BUT. I make really good things, maybe they aren't perfect, but people really like them. Surely, surely Google could have used that.
Actually, no. There's no level of rockstarness that excuses being a dick and difficult to work with. That kind of attitude can turn a whole team's culture sour and result in way more damage than any one person can make up for through their individual contributions.
It's clear from reading his thoughts on the matter why Google didn't hire him, and it's also clear he still doesn't understand why either.
Actually, no. There's no level of rockstarness that excuses being a dick and difficult to work with. That kind of attitude can turn a whole team's culture sour and result in way more damage than any one person can make up for through their individual contributions.
It's clear from reading his thoughts on the matter why Google didn't hire him, and it's also clear he still doesn't understand why either.
Yeah, my takeaway from his telling of the story was that he is someone I would give a Strong No to, and not because of anything related to his CS ability. The fact that he wrote that after an unsuccessful short tenure at Apple where he ran into the exact same problems as he would have at Google yet still thinks Google should have hired him just reinforces that.
Absolutely this. I sense no work ethic, no humility (“I make really good things“). This, from my experience, usually correlates with an overgrown ego and unwillingness to confess to a mistake allowing to act quickly to mitigate the side effects. So when it actually happens the damage can be catastrophic.
> I am often a dick, I am often difficult, I often don’t know computer science, but. BUT.
I'll stop him right there. Definitely not googley.
I'll stop him right there. Definitely not googley.
Yep. And I don't know the story and certainly wasn't there - but technical prowess alone doesn't get you the job. And honestly he may not be a good fit. Is he going to want to fix bugs or work on Google's schedule and have a boss? Some people aren't cut out for the work lifestyle.
a dreaded quora question answered by Max Howell - https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
We need to move on from this particular gossips/memes.
>turned down by Apple and Google
It was Google. Because he didn't know what a binary tree was or something similar during the infamous Whiteboard test.
But I mean it make perfect sense. Google is all about building AI, ML, Algorithm, K8S etc. Complexity is their KPI, usefulness is not.
So may be it isn't so much a bad thing after all. He wouldn't have fit in.
Edit: I guess the tone didn't shine through. The "all about" is a figure of speech. A more accurate wording would be, in my opinion Google doesn't know how to built great "user" Product.
And I may also include some of the Google hiring practice [1] that were brought to twitter.
[1] https://twitter.com/shaft/status/1355696154990628864?s=20
It was Google. Because he didn't know what a binary tree was or something similar during the infamous Whiteboard test.
But I mean it make perfect sense. Google is all about building AI, ML, Algorithm, K8S etc. Complexity is their KPI, usefulness is not.
So may be it isn't so much a bad thing after all. He wouldn't have fit in.
Edit: I guess the tone didn't shine through. The "all about" is a figure of speech. A more accurate wording would be, in my opinion Google doesn't know how to built great "user" Product.
And I may also include some of the Google hiring practice [1] that were brought to twitter.
[1] https://twitter.com/shaft/status/1355696154990628864?s=20
I completely disagree with this comment. Not to mention the comments to his Quora answer, suggesting he should try a TPM position... people are so out of touch.
The main problem is that he went through the standard interview process. To prevent bias you need to maintain a consistent interview process and bar. All interviewers in big tech have annual trainings about this. If someone underperforms it's considered bad judgment to be inclined based on who the person is or their past experience. This is to prevent cases like "he didn't do well but we should hire him anyway because he graduated from Stanford".
When you have someone who is an exception you shouldn't hire them via the standard interview process. Maybe Google didn't think he's an exception. But the reality is, the vast majority of Google engineers wouldn't be able to build something as successful from scratch like he did. It requires more skills than just being a good engineer. They could've found him a role that fits his skills. When FB hired Yann Lecun I'm sure they didn't ask him how SVMs work. (not saying they are on the same level, clearly not, just an extreme example)
Another possible option is that he came across too arrogant in more than one interview and the hiring committee was worried he wouldn't be a good fit culturally.
The main problem is that he went through the standard interview process. To prevent bias you need to maintain a consistent interview process and bar. All interviewers in big tech have annual trainings about this. If someone underperforms it's considered bad judgment to be inclined based on who the person is or their past experience. This is to prevent cases like "he didn't do well but we should hire him anyway because he graduated from Stanford".
When you have someone who is an exception you shouldn't hire them via the standard interview process. Maybe Google didn't think he's an exception. But the reality is, the vast majority of Google engineers wouldn't be able to build something as successful from scratch like he did. It requires more skills than just being a good engineer. They could've found him a role that fits his skills. When FB hired Yann Lecun I'm sure they didn't ask him how SVMs work. (not saying they are on the same level, clearly not, just an extreme example)
Another possible option is that he came across too arrogant in more than one interview and the hiring committee was worried he wouldn't be a good fit culturally.
That sounds about right. I'm guessing the last time I was hired it wouldn't have happened through a "standard interview process" because my background is somewhat eclectic and I frankly probably wouldn't tick enough of the boxes for obvious positions I might have been inclined to apply for. But people knew me, a job description was written for me, and here I am quite a few years later.
This seems off - based on most interactions Googlers and especially ex-Googlers, arrogance must be a practical requirement to work there.
From the many folks I know there the arrogance is learned once you join (and exceptionally easy to do so), but it's not a pre-requisite.
> Google is all about building AI, ML, Algorithm, K8S
No, no big companies are "all about" anything, there is so many different areas of work, that rejecting a person because the company is "all about" X, doesn't really apply. If they wanted to work with him, they would have made it work. But they didn't, so they didn't.
No, no big companies are "all about" anything, there is so many different areas of work, that rejecting a person because the company is "all about" X, doesn't really apply. If they wanted to work with him, they would have made it work. But they didn't, so they didn't.
You are right, certainly there could be a fit, but finding the right place for someone implies that the hiring decision has already been made.
For me, it sounds like he applied for a standard software developer job through the standard process. Would you hire someone as a software developer without knowing the basics?
From that resume, I would see him rather in a product owner role or some other full or semi-management position.
For me, it sounds like he applied for a standard software developer job through the standard process. Would you hire someone as a software developer without knowing the basics?
From that resume, I would see him rather in a product owner role or some other full or semi-management position.
It also made sense that they'd make an absolute dogs dinner of golang package management after turning him down.
Some things are not in google's DNA.
Some things are not in google's DNA.
I think golang's handling of packages makes a lot of sense... if you're Google, and you have a huge monorepo anyway.
I think this reasoning explains a lot of my frustrations with Go: it's Google's language that they kindly let you use, it didn't grow organically within many communities and companies across a whole range of use cases and codebase sizes.
You have a similar thing with git, it was the kernel's VCS that you could also use if you wanted, but especially early on it was rather hostile if you didn't actually need to maintain a gigabyte-sized monorepo with hundreds of third-party contributors mailing patches to various subsystem maintainers that would then have their branches merged into the mainline. Fortunately git's usability has improved a lot since then.
I think this reasoning explains a lot of my frustrations with Go: it's Google's language that they kindly let you use, it didn't grow organically within many communities and companies across a whole range of use cases and codebase sizes.
You have a similar thing with git, it was the kernel's VCS that you could also use if you wanted, but especially early on it was rather hostile if you didn't actually need to maintain a gigabyte-sized monorepo with hundreds of third-party contributors mailing patches to various subsystem maintainers that would then have their branches merged into the mainline. Fortunately git's usability has improved a lot since then.
Google is not all about that
I agree. Is Brew perfect? No, far from it. But I think that given the tools available at the time, Brew is the right balance between technically good and being really easy to use. The dependence on git means speed isn't great, especially if you don't use it often, but it keeps things simple and maintainable. I also think it's been fantastic to see the level of support from the community and the efforts of the maintainers. For example, merging Linuxbrew back into Homebrew itself.
Honestly I can't imagine using my mac without Brew.
Honestly I can't imagine using my mac without Brew.
Thank you so much. Comments like yours are what keeps us going. Much appreciated!
Thanks to Max Howell for having the initial vision and maintaining it for the first 4 years!
Thanks to Mike McQuaid (et al) for the last 10!
https://github.com/Homebrew/brew/graphs/contributors
Thanks to Mike McQuaid (et al) for the last 10!
https://github.com/Homebrew/brew/graphs/contributors
I don't think homebrew has more user than say apt or pacman. Maybe there are a bit more people running osx than linux, but much of them are not devs or "power users" and never run homebrew.
Apt I can agree, it's still the gold standard of package manager and powers the most popular distributions out there in bajillion cloud instances.
Pacman, erm what? Arc is a niche of a niche. I'd bet Alpine's package manager sees more action than that - let alone yum/rpm.
Pacman, erm what? Arc is a niche of a niche. I'd bet Alpine's package manager sees more action than that - let alone yum/rpm.
I have friends working on debian based distro, following their discussions on a lot of dpkg packaging intricacies is crazy. However that also means it's mature piece of software that handle many cases under the sky of software packaging and distribution.
Besides, we all know that pacman is nothing compared to the one true package manager, portage.
I would say he's stuck in the shitty interface between truly creative people and macos.
I think creative people are getting the shaft from apple.
"Here's to the crazy ones" went out the window, maybe with the end of the Steve era. If you don't do it the apple way, apple doesn't care.
I mean, they support the xcode factory workers with apple languages. It's the apple equivalent of visual studio. But its sort of monochrome (like the 1984 ad)
I truly believe apple itself should have more direct/overt support for other software on their platform in a macports/homebrew way. (scripting languages?)
xquartz is sort of an example of this "forgotten lawn furniture left out in the rain". It's critical to a lot of mac users, but they distance themselves from it. Gah, at least bring it indoors when there's snow on the ground.
I think creative people are getting the shaft from apple.
"Here's to the crazy ones" went out the window, maybe with the end of the Steve era. If you don't do it the apple way, apple doesn't care.
I mean, they support the xcode factory workers with apple languages. It's the apple equivalent of visual studio. But its sort of monochrome (like the 1984 ad)
I truly believe apple itself should have more direct/overt support for other software on their platform in a macports/homebrew way. (scripting languages?)
xquartz is sort of an example of this "forgotten lawn furniture left out in the rain". It's critical to a lot of mac users, but they distance themselves from it. Gah, at least bring it indoors when there's snow on the ground.
You would have been happy with ArchMac[0] then.
Unfortunately after a dozen or so years as sole maintainer and user I dropped it a month ago[1].
If anyone wants to take over just reach out.
(not in the post but I had to pull the DO storage because I was severely out of cash, I still have the packages locally)
[0]: https://www.archmac.org/
[1]: https://lna7n.org/2020/01/06/pulling-the-plug-on-archmac.htm...
Unfortunately after a dozen or so years as sole maintainer and user I dropped it a month ago[1].
If anyone wants to take over just reach out.
(not in the post but I had to pull the DO storage because I was severely out of cash, I still have the packages locally)
[0]: https://www.archmac.org/
[1]: https://lna7n.org/2020/01/06/pulling-the-plug-on-archmac.htm...
But can he invert a binary tree?
"But well, what the fuck does comp-sci have to do with modern app development?" [1]
[1] Max Howell, https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
[1] Max Howell, https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
remix2000(1)
I only use it because IT forces Macs down our throats. It's understandable, the hardware is light years ahead of any other manufacturer, along with the OS support. But I just do the bare minimum of setup to get VNC and SSH working and GTFO to a proper remote dev box.
> But I just do the bare minimum of setup to get VNC and SSH working
Lucky for you those are both fully supported out-of-the-box, and have been for a couple of decades. Sounds like your IT team is forcing the right solution down your throats.
Lucky for you those are both fully supported out-of-the-box, and have been for a couple of decades. Sounds like your IT team is forcing the right solution down your throats.
It's a matter of opinion and the opiner I guess. To go from factory OS to be able to run what's on the server side is not simple, and has been brittle. For me a better solution would be a Linux native box with the same distro & configuration to be able to avoid the VNC remote altogether. But for the company, perhaps that kind of solution would have costs in support and maintenance that would make it a bad choice.
>
I use Linux at home and package managers like AUR are great, but macOS is where the users are.
Windows is where the users are, and apt-get works just as well on WSL2 as natively.
Windows is where the users are, and apt-get works just as well on WSL2 as natively.
The fact that AAPL doesn't support brew's maintenance and development is a great reason to not buy more macs.
They support them with Hardware and technical resources. Seeing what happened with the whole CentOS mess, I am kind of glad that homebrew remains independent and can continue to do so without relying on Apple’s money.
Apple is invested into MacPorts (and also pays several employees working on it).
To be fair, I think the number of employees specifically paid to work on MacPorts is probably zero. The ones that do work on it seemingly do it in addition to their regular duties.
I don't understand if there are implications to upgrading to homebrew 3.0 for me a lowly user. Will things break? Will I lose access to formulae that haven't yet been upgraded to work with brew 3.0?
Should I upgrade right away or hold off for a while? Which is least likely to interupt my workflow in which I count on brew just working?
Should I upgrade right away or hold off for a while? Which is least likely to interupt my workflow in which I count on brew just working?
Homebrew generally doesn't do breaking changes. I haven't experienced any disruption... this version seems to be a headliner for full Apple Silicon support. Even if there are any changes, `brew doctor` usually handles things for you.
Thanks! I know homebrew doesn't generally do breaking changes, but they also don't generally do major version releases, which can sometimes be a signal for breaking changes, thus my concern!
I agree. Any type of "migration guide" that I should be aware of?
They mention that ["various methods have been deprecated, disabled and removed"][0] but its hard to read from that PR exactly which commands no longer work.
Thanks for all the great work on homebrew!
0: https://github.com/Homebrew/brew/pull/10397
They mention that ["various methods have been deprecated, disabled and removed"][0] but its hard to read from that PR exactly which commands no longer work.
Thanks for all the great work on homebrew!
0: https://github.com/Homebrew/brew/pull/10397
I'm a lowly, very dumb user too. I ran Brew doctor and realized that the default installation is now in /opt/homebrew (which to my dumb ears seems like it solves most complaints I've heard about Homebrew).
Since Homebrew threw a warning at me with my old install in /usr/local, I completely uninstalled and reinstalled Homebrew 3.0.
Since Homebrew threw a warning at me with my old install in /usr/local, I completely uninstalled and reinstalled Homebrew 3.0.
Homebrew will automatically update the next time you use the install, tap, update, or upgrade command, unless you have HOMEBREW_NO_AUTO_UPDATE set to 1
i migrated with brew bundle in a fresh install and it worked wonderfully.
i've never even heard of "brew bundle". Not sure if you're suggesting I need to do a "fresh install", or how I'd do that! But I can google!
I guess I was sort of expecting some migration instructions with the release notes...
I guess I was sort of expecting some migration instructions with the release notes...
Been a MacPorts user for years and I know nothing about Homebrew. To those who tried both: should a software engineer switch to Homebrew?
MacPorts has its own way of dealing with dev tools and framework versioning. E.g. you can have multiple versions of complex products like PHP or MySQL at once. You can even have a GCC package for a specific target arch as a separate ports package. Does Homebrew allow these things?
MacPorts has its own way of dealing with dev tools and framework versioning. E.g. you can have multiple versions of complex products like PHP or MySQL at once. You can even have a GCC package for a specific target arch as a separate ports package. Does Homebrew allow these things?
MacPorts and Homebrew have a different philosophy of software installation.
MacPorts wants to have its own thing over in /opt where it has its own toolchain independent from the system tool chain.
This means that all users on the system share the same MacPorts software. This has an additional impact that it means that it requires privilege to install software there.
Homebrew, on the other hand, uses the system toolchain and tries to avoid using root.
In today's world, the "multiple versions of complex products like PHP or MySQL at once" isn't a compelling argument for me as I use docker to solve that problem.
MacPorts wants to have its own thing over in /opt where it has its own toolchain independent from the system tool chain.
This means that all users on the system share the same MacPorts software. This has an additional impact that it means that it requires privilege to install software there.
Homebrew, on the other hand, uses the system toolchain and tries to avoid using root.
In today's world, the "multiple versions of complex products like PHP or MySQL at once" isn't a compelling argument for me as I use docker to solve that problem.
> This means that all users on the system share the same MacPorts software. This has an additional impact that it means that it requires privilege to install software there.
> Homebrew, on the other hand, uses the system toolchain and tries to avoid using root.
What? Homebrew wants you to change ownership of /usr/local to your individual user and refuses to run without doing so. How is that any different as far "as all users on the system share the same software?"
> Homebrew, on the other hand, uses the system toolchain and tries to avoid using root.
What? Homebrew wants you to change ownership of /usr/local to your individual user and refuses to run without doing so. How is that any different as far "as all users on the system share the same software?"
> Homebrew wants you to change ownership of /usr/local to your individual user
If I read homebrew's install.sh correctly, it changes ownership of a few directories under /usr/local, not /usr/local itself (on x86, on ARM it follows a different path). This matches how my current Mac, which has brew, is currently setup as well.
If I read homebrew's install.sh correctly, it changes ownership of a few directories under /usr/local, not /usr/local itself (on x86, on ARM it follows a different path). This matches how my current Mac, which has brew, is currently setup as well.
# Required installation paths. To install elsewhere (which is unsupported)
# you can untar https://github.com/Homebrew/brew/tarball/master
# anywhere you like.
...
# On Intel macOS, this script installs to /usr/local only
HOMEBREW_PREFIX="/usr/local"
...
directories=(bin etc include lib sbin share opt var
Frameworks
etc/bash_completion.d lib/pkgconfig
share/aclocal share/doc share/info share/locale share/man
share/man/man1 share/man/man2 share/man/man3 share/man/man4
share/man/man5 share/man/man6 share/man/man7 share/man/man8
var/log var/homebrew var/homebrew/linked
bin/brew)
group_chmods=()
for dir in "${directories[@]}"; do
if exists_but_not_writable "${HOMEBREW_PREFIX}/${dir}"; then
group_chmods+=("${HOMEBREW_PREFIX}/${dir}")
fi
done
... and further on, after some checks, group_chmods turns into chowns ...
if [[ "${#chowns[@]}" -gt 0 ]]; then
ohai "The following existing directories will have their owner set to ${tty_underline}${USER}${tty_reset}:"
printf "%s\n" "${chowns[@]}"
fiParent's information is outdated, but originally/historically Homebrew did want you to chown /usr/local
Actually (I can't edit the original comment anymore) it looks like they were still recommending this as recently as last year?? https://discourse.brew.sh/t/permission-problems/3011/29
Haven't used Homebrew in quite a time, so I'm not sure.
Haven't used Homebrew in quite a time, so I'm not sure.
As recently as like, 1-3 months ago, yeah? I would have tried to install homebrew for the first time sometime December 2020 or later.
Huh? I'm on Big Sur running homebrew.
'ls -l /usr' reveals that /usr/local is root:wheel just like all other folders under /usr. How exactly is homebrew changing ownership?
'ls -l /usr' reveals that /usr/local is root:wheel just like all other folders under /usr. How exactly is homebrew changing ownership?
Any chance you're on Apple Silicon? For some reason homebrew uses /usr/local on Intel macs and /opt/homebrew on ARM macs.
Anyway, this requirement is well documented and not new:
https://github.com/Homebrew/brew/issues?q=is%3Aissue+%2Fusr%...
http://github.com/Homebrew/brew/blob/master/docs/Installatio...
Homebrew asks users (on Intel macs) to change the ownership of /usr/local to their local user. And it refuses to run under sudo.
Anyway, this requirement is well documented and not new:
https://github.com/Homebrew/brew/issues?q=is%3Aissue+%2Fusr%...
http://github.com/Homebrew/brew/blob/master/docs/Installatio...
Homebrew asks users (on Intel macs) to change the ownership of /usr/local to their local user. And it refuses to run under sudo.
> Homebrew asks users (on Intel macs) to change the ownership of /usr/local to their local user.
Nope - intel Mac on Big Sur:
drogers@SJCMACJDYMD6M ~ % ls -l /usr
[snip]
drwxr-xr-x 15 root wheel 480 Dec 14 20:10 local
[end snip]
And for the record, neither of your links support your claim.
Nope - intel Mac on Big Sur:
drogers@SJCMACJDYMD6M ~ % ls -l /usr
[snip]
drwxr-xr-x 15 root wheel 480 Dec 14 20:10 local
[end snip]
And for the record, neither of your links support your claim.
This changed in the last few years (I don't recall the exact date), but it absolutely was the way that brew operated for many years.
https://apple.stackexchange.com/questions/1393/are-my-permis...
https://superuser.com/questions/1264673/chown-usr-local-oper...
https://apple.stackexchange.com/questions/1393/are-my-permis...
https://superuser.com/questions/1264673/chown-usr-local-oper...
>Any chance you're on Apple Silicon?
No, I'm on an Intel chip, not M1.
>Homebrew asks users (on Intel macs) to change the ownership of /usr/local to their local user. And it refuses to run under sudo.
Again, no, not on my machine it doesn't. /usr/local is root:wheel. This is a newish (to me) machine that I gave first birthday to beginning of December 2020. The first thing I did was installed brew and started installing the things that makes my computer useful to me. No permissions were asked to be changed.
No, I'm on an Intel chip, not M1.
>Homebrew asks users (on Intel macs) to change the ownership of /usr/local to their local user. And it refuses to run under sudo.
Again, no, not on my machine it doesn't. /usr/local is root:wheel. This is a newish (to me) machine that I gave first birthday to beginning of December 2020. The first thing I did was installed brew and started installing the things that makes my computer useful to me. No permissions were asked to be changed.
https://stackoverflow.com/questions/16432071/how-to-fix-home...
Dunno if it needs this now anymore -- i think they moved to /usr/local/Homebrew some time ago -- but this was a big deal for a few years
Dunno if it needs this now anymore -- i think they moved to /usr/local/Homebrew some time ago -- but this was a big deal for a few years
Given the moving nature of the OSX toolchain and directory structure, having your third party package manager integrated into the system toolchain increasingly feels like a bad idea.
The flip side of that is "do you want to have two scripting and compiler toolchains installed on the machine - one that gets updates from the vendor and one that gets updates from volunteers?"
The spot where this becomes an issue would be say... (making up a story here) there's a vulnerability found in Ruby which is part of the toolchain for the system and in MacPorts toolchain. Apple pushes out a security update that updates the system toolchain... but the issue in the MacPorts toolchain remains until that is updated.
I had an issue with MacPorts many years ago when I was trying to install a python library via MacPorts (I forget exactly why) but wasn't being found with python on the command line (which was using the system toolchain) and then when I resolved the "I'm using the MacPorts version on the command line" other issues with software that was expecting the system toolchain version started cropping up.
That's a "my experience" story and isn't meant to be defining.
I believe that both Homebrew and MacPorts have made design choices that reflect how they want to take their respective projects and I respect those design choices. They solve problems in different ways and have different repercussions for how users use them.
For me, on my systems, I've found that I tend to prefer to fix the problems that Homebrew causes than the problems that MacPorts causes. The big thing that made that preferable is that the services (databases and such) are not run on the bare machine but rather in containers.
The spot where this becomes an issue would be say... (making up a story here) there's a vulnerability found in Ruby which is part of the toolchain for the system and in MacPorts toolchain. Apple pushes out a security update that updates the system toolchain... but the issue in the MacPorts toolchain remains until that is updated.
I had an issue with MacPorts many years ago when I was trying to install a python library via MacPorts (I forget exactly why) but wasn't being found with python on the command line (which was using the system toolchain) and then when I resolved the "I'm using the MacPorts version on the command line" other issues with software that was expecting the system toolchain version started cropping up.
That's a "my experience" story and isn't meant to be defining.
I believe that both Homebrew and MacPorts have made design choices that reflect how they want to take their respective projects and I respect those design choices. They solve problems in different ways and have different repercussions for how users use them.
For me, on my systems, I've found that I tend to prefer to fix the problems that Homebrew causes than the problems that MacPorts causes. The big thing that made that preferable is that the services (databases and such) are not run on the bare machine but rather in containers.
Containers cover some use cases but not all. Experimentation for one, also if you need specific compiler toolchains that you occasionally use on your sources. You don't create a Docker image each time you need a specific toolchain. MacPorts definitely shines here but it's probably not a great option for non-technical users.
Fwiw you can use the Nix package manager (https://nixos.org/) on OS X to accomplish those same things. Lots of discussion about that the past few years:
https://google.com/?q=nix+on+mac+os+x
Nix has more packages than MacPorts - 60k vs 37.6k - though that's not necessarily a guarantee the ones you need are there.
And like MacPorts it doesn't do weird, non-Unix-y ownership changes of system directories like Homebrew does.
https://google.com/?q=nix+on+mac+os+x
Nix has more packages than MacPorts - 60k vs 37.6k - though that's not necessarily a guarantee the ones you need are there.
And like MacPorts it doesn't do weird, non-Unix-y ownership changes of system directories like Homebrew does.
How is that better than a pm specifically designed for Mac?
I use Homebrew, and am genuinely appreciative of the amount of effort all the contributors have put in. However, as far as package managers go, it's kind of awful.
Homebrew excels as a mechanism to install the latest software, if you don't care about breaking things. However, traditionally a package manager's job is to ensure that if you've installed something, it'll continue to run.
If you've ever updated readline via Homebrew, you can pretty much just watch everything burn.
If you've ever tried to use an old version of Postgres, good luck. Particularly if you're wanting to mix and match versions of PostGIS.
If you're running an old version of macOS, you're out in the cold. Although, I must admit, recently this seems to be handled much better.
Homebrew excels as a mechanism to install the latest software, if you don't care about breaking things. However, traditionally a package manager's job is to ensure that if you've installed something, it'll continue to run.
If you've ever updated readline via Homebrew, you can pretty much just watch everything burn.
If you've ever tried to use an old version of Postgres, good luck. Particularly if you're wanting to mix and match versions of PostGIS.
If you're running an old version of macOS, you're out in the cold. Although, I must admit, recently this seems to be handled much better.
Also any random operation can take 20 minutes to complete if you haven't used brew in a while.
You can disable this but I agree, I hate it.
This comment actually just spurred me to find this (https://gist.github.com/jb510/99f12b1ac70f1cf8b780) which may fix the issue of forgetting to manually update.
This comment actually just spurred me to find this (https://gist.github.com/jb510/99f12b1ac70f1cf8b780) which may fix the issue of forgetting to manually update.
I understand why they did it, but it’s super annoying.
Given the intervals between running Homebrew, you just know it’s going to spin for a minute or two updating every damn time you try to use it, usually when you want something installed fast.
Given the intervals between running Homebrew, you just know it’s going to spin for a minute or two updating every damn time you try to use it, usually when you want something installed fast.
Have you tried MacPorts?
Not in about 8 years. I do most of my development in Docker these days so tend to make use of Linux package managers.
MacPorts has been virtually flawless for me in the last 16 years. Worth a try.
It probably depends on what you want?
If you like treating your Mac like a very MacMacMac pet, a pm designed for Mac is probably better.
If you'd like to treat your Mac like UnixMac livestock, you probably want a cross-platform pm.
Using Nix means the core of my dev needs are met by config shared between my NixOS and macOS systems, with some idiomatic unshareable bits around the edges.
(I don't want to trivialize the gaps or over-sell Nix here. Nix forms a foundation for accomplishing this, but I do still have non-trivial bootstrap scripts for macOS.)
If you like treating your Mac like a very MacMacMac pet, a pm designed for Mac is probably better.
If you'd like to treat your Mac like UnixMac livestock, you probably want a cross-platform pm.
Using Nix means the core of my dev needs are met by config shared between my NixOS and macOS systems, with some idiomatic unshareable bits around the edges.
(I don't want to trivialize the gaps or over-sell Nix here. Nix forms a foundation for accomplishing this, but I do still have non-trivial bootstrap scripts for macOS.)
Are you talking about Homerew or MacPorts?
Unfortunately, Nixpkg doesn't check buildability on Darwin when merging PRs, so things can break quite often on the nixpkgs-unstable channel (compared to nixpkgs-unstable on Linux). It's not hard to rollback, though, but it does makes me never want to ever run `nix-channel --update`.
I feel similarly and am a little careful about when I choose to take an update.
That said, I think most people want darwin failures to be able to block, so it's mostly about getting on top of them to the point where it's practical to keep them triaged. Domen is working on getting a part-time position funded to work on issues here (https://opencollective.com/nix-macos), though individual package breaks are probably down the list.
That said, I think most people want darwin failures to be able to block, so it's mostly about getting on top of them to the point where it's practical to keep them triaged. Domen is working on getting a part-time position funded to work on issues here (https://opencollective.com/nix-macos), though individual package breaks are probably down the list.
nixpkgs CI does check for buildability on Darwin, which can be confirmed by looking at any of their PRs. However, packages do tend to be get marked as broken on Darwin if it doesn’t build and the packager doesn’t own a Mac.
I feel things have stabilized significantly in recent days, though. I haven’t had a single Darwin breakage on the unstable channel since the release of 20.09. Perhaps the Zero Hydra Failures effort[1] helped.
[1]: https://github.com/NixOS/nixpkgs/issues/97479
I feel things have stabilized significantly in recent days, though. I haven’t had a single Darwin breakage on the unstable channel since the release of 20.09. Perhaps the Zero Hydra Failures effort[1] helped.
[1]: https://github.com/NixOS/nixpkgs/issues/97479
I think what I meant was darwin failure doesn't block.
Recently I had nomad breakage on -unstable caused by nvml support, which pulls in nvidia_x11, which pulls in linux_5_4, which of course not installable on darwin[1]. The maintainer fixed it very quickly (thank you!) but I still need to wait few more days for it to be included in -unstable.
[1]: https://github.com/NixOS/nixpkgs/issues/108603
Recently I had nomad breakage on -unstable caused by nvml support, which pulls in nvidia_x11, which pulls in linux_5_4, which of course not installable on darwin[1]. The maintainer fixed it very quickly (thank you!) but I still need to wait few more days for it to be included in -unstable.
[1]: https://github.com/NixOS/nixpkgs/issues/108603
Use one of the Darwin channels, that won't advance unless Darwin things are not too broken.
Here’s a blog post from April 2019 on package managers on macOS. [1] The author, saagarjha (who also comments here regularly), switched from homebrew to MacPorts. A more current update to this post would probably be more helpful.
In my limited experience, I’ve tried homebrew a few times, but found it a bit cumbersome with the “no sudo” requirement.
[1]: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
In my limited experience, I’ve tried homebrew a few times, but found it a bit cumbersome with the “no sudo” requirement.
[1]: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
This is very interesting, and maybe sheds light on why Google decided not to hire Max. There seems to be some consensus that MacPorts has the better architecture, while Homebrew has been better at responding to users, even according to Max himself.
For Google, it's likely the former is more important than the latter for a lot of their projects. An architecture that doesn't scale or doesn't always do the right thing or sometimes messes up data, can be catastrophic at the scale of Google.
For Google, it's likely the former is more important than the latter for a lot of their projects. An architecture that doesn't scale or doesn't always do the right thing or sometimes messes up data, can be catastrophic at the scale of Google.
> maybe sheds light on why Google decided not to hire Max.
This is the sort of myths we hold about interviews. That the company is doing such deep dive on us that they are reading our Github commits and considering the trade-offs of MacPorts vs. Homebrew architecture.
This is the sort of myths we hold about interviews. That the company is doing such deep dive on us that they are reading our Github commits and considering the trade-offs of MacPorts vs. Homebrew architecture.
I promise you that Homebrew is operating "at scale." Considering that Google hires many kids straight out of school who have never built any significant real-world software at all, I think this hypothesis is highly unlikely.
> There seems to be some consensus that MacPorts has the better architecture
There isn’t, Homebrew is far superior in my opinion, and everyone I know using a Mac. We all left MacPorts ages ago.
It’s safe to say that has nothing to do with him not getting the job.
There isn’t, Homebrew is far superior in my opinion, and everyone I know using a Mac. We all left MacPorts ages ago.
It’s safe to say that has nothing to do with him not getting the job.
> found it a bit cumbersome with the “no sudo” requirement
This is one of the few features I do love about Homebrew. Does MacPorts have a "no sudo" mode or does it just let all packages run rampant on your system?
This is one of the few features I do love about Homebrew. Does MacPorts have a "no sudo" mode or does it just let all packages run rampant on your system?
My understanding is that the whole reason for running the outer commands as sudo is so that the inner build/install commands can be run in a far more restricted environment. Because brew runs as your own user, every build has access to your entire home directory, the whole homebrew folder, etc. It's nice in principle to not have to "trust" any of homebrew with sudo, but in reality, the trust surface area is far larger. With MacPorts, you only have to trust the tooling, not the individual package definitions (though obviously the calculus does change slightly when bottles are in the picture, since then the build/install is happening elsewhere).
Relevant: https://xkcd.com/1200/
Relevant: https://xkcd.com/1200/
I am confused by this. sudo seems like a far larger surface area than running as me. If it's just me then it's just me, but if it's sudo, then it's the entire box.
It depends whether you trust the tool maintainers more than the package definition maintainers. I certainly would. But don't take my word for it— here's a MacPorts developer explaining the sandboxing of builds:
https://apple.stackexchange.com/a/106942
https://apple.stackexchange.com/a/106942
> Directories listed in multiple users' $PATH that are writable without superuser privileges can be used for attacks (e.g., by placing a sudo binary that will log the password there). The same can be done by malicious software running as your user in order to get your password
Yikes. That particular attack did not occur to me.
Yikes. That particular attack did not occur to me.
Thank you for this link. This is the first robust argument for running as root that I've seen, and completely upends my assumptions.
I'd been considering trying macports but this has convinced me.
I'd been considering trying macports but this has convinced me.
> inner build/install commands can be run in a far more restricted environment
As I seem to remember it, homebrew rankles if you use sudo but also complains if you’re not an admin account, which struck me as ironic and irritating all at once, and means that xkcd isn’t quite as relevant.
As I seem to remember it, homebrew rankles if you use sudo but also complains if you’re not an admin account, which struck me as ironic and irritating all at once, and means that xkcd isn’t quite as relevant.
> every build has access to your entire home directory, the whole homebrew folder, etc.
Isn't this just whataboutism though? Yes that's potentially a problem but it's an orthogonal one. So not really relevant to this discussion.
A hypothetical solution to the problem in the linked XKCD would be to somehow prevent an attacker accessing your bank, it would not be to allow an attacker to install drivers without your permission.
> With MacPorts, you only have to trust the tooling, not the individual package definitions (though obviously the calculus does change slightly when bottles are in the picture, since then the build/install is happening elsewhere).
This calculus change is basically my primary concern.
Of course it's not ideal that Homebrew apps have access to everything in my Home, but that's still better than them having access to everything on my system.
Isn't this just whataboutism though? Yes that's potentially a problem but it's an orthogonal one. So not really relevant to this discussion.
A hypothetical solution to the problem in the linked XKCD would be to somehow prevent an attacker accessing your bank, it would not be to allow an attacker to install drivers without your permission.
> With MacPorts, you only have to trust the tooling, not the individual package definitions (though obviously the calculus does change slightly when bottles are in the picture, since then the build/install is happening elsewhere).
This calculus change is basically my primary concern.
Of course it's not ideal that Homebrew apps have access to everything in my Home, but that's still better than them having access to everything on my system.
The point is that they wouldn't. Only the core brew utility would, because in almost all cases, it would be immediately downgrading itself to either a dedicated homebrew user, or in the case of builds, to a nobody user who does its work in /tmp and only has write access to the one install path it has been allocated (which is then chowned to the brew user afterward).
The fundamental issue is that the POSIX user model has no concept of one user being strictly less privileged than another, and therefore all impersonations require root.
And note that the situation on Debian and Ubuntu is much worse than either of these models, because every package has an opportunity to run arbitrary commands as root as part of the postinstall and at various other times during the package lifecycle. So basically you've owned yourself the first time you add some user's random PPA and run `apt dist-upgrade` to pull new versions from it.
The fundamental issue is that the POSIX user model has no concept of one user being strictly less privileged than another, and therefore all impersonations require root.
And note that the situation on Debian and Ubuntu is much worse than either of these models, because every package has an opportunity to run arbitrary commands as root as part of the postinstall and at various other times during the package lifecycle. So basically you've owned yourself the first time you add some user's random PPA and run `apt dist-upgrade` to pull new versions from it.
The problem is that the way they do it breaks the UNIX model. /usr/local is common to all users, but Homebrew gives it the current user's permissions. This consequently creates weirdness if you actually use multiple user accounts.
Exactly why I prefixed my comment with "this is one of the FEW features I do love". The exact technical approach Hombrew ends up taking to a lot of problems always seems not quite right whenever I've dug a little deeper.
Fair point, but I bet the number of Macs in the wild shared by multiple people who would want to run Homebrew are vanishingly small.
Sure, but it's a native feature built into the Mac platform. If software is going to prevent that from working properly, then that should be communicated very clearly.
Is this an issue in practice in more than a rounding error number of Macs? I'd bet lots of money that the vast majority of developers (that is, people likely to be installing Homebrew in the first place) are using effectively single-user systems.
I'm not sure about unprivileged installs, but MacPorts is very good about sticking to /opt/local. It doesn't ever place anything (including config files) outside of /opt/local. So you get pretty good assurance that it won't trash your system too badly.
And, they actually enforce this with a specially provisioned MacPorts user. So although it requires sudo, MacPorts installs don’t actually run as root.
Yes, it does; you can just configure it with --prefix (to move it out of /opt/local) and --with-no-root-privileges. The downside is that you won't be able to use the binary packages anymore, but I think that is true for Homebrew as well.
I find that MacPorts is a better citizen of my laptop, but the mindshare of homebrew means that brew will have both more packages and more up to date packages.
And getting the tools team at work to vend both brew and macports seems malicious so I just suck it up there.
And getting the tools team at work to vend both brew and macports seems malicious so I just suck it up there.
I don’t use homebrew (for many of the reasons found in the comments here and more) but this is why I do visit their repo[1] for a “formula” whenever I need something macports or pkgsrc can’t supply me.
[1] https://github.com/Homebrew/homebrew-core/blob/master/Formul...
[1] https://github.com/Homebrew/homebrew-core/blob/master/Formul...
I think that's the key, MacPorts stays in its lane. I also like the variant mechanism. It makes it easy (much like OpenBSD flavors) to get what I want out of it.
Have never used MacPorts, but based on your comment, and a few of the replies, I may give it a try. Homebrew is quite painful in many ways, particularly when managing multiple versions of a package (MySQL & PostgreSQL especially has had a lot of issues for me).
On the other hand, what I will say in favour of Homebrew is that its popularity does make life much easier as there's so much software available on it. Even very small / niche / new projects will often have a Homebrew package.
On the other hand, what I will say in favour of Homebrew is that its popularity does make life much easier as there's so much software available on it. Even very small / niche / new projects will often have a Homebrew package.
This Homebrew MacPorts discussion is giving me a MySQL Postgres vibe.
The former is more popular and easier to get started with and bigger community, but the latter is higher quality and better designed.
The former is more popular and easier to get started with and bigger community, but the latter is higher quality and better designed.
You would probably enjoy the `port select` command in Macports to pick the version you want to launch when invoking, say, "python".
Macports is also good about naming different versions, so you can have python-34, python-37, and python-29 installed together.
Macports is also good about naming different versions, so you can have python-34, python-37, and python-29 installed together.
My experience with homebrew is that it doesn't deal well with multiple version of packages at the same time. For example, it doesn't like to keep outdated openssl in parallel, which is good from a security standpoint but can make it difficult if your job involves a lot of looking at antique codebases and help with updating them...
It's why I switched back to macports after briefly testing it
Can you explain exactly what you are describing:
“it doesnt deal well with multiple versions at the same time”
Also what system/os are you comparing to?
“it doesnt deal well with multiple versions at the same time”
Also what system/os are you comparing to?
I'm comparing to macports. I remember a brew update that removed an old version of openssl causing all of my older ruby packages to fail. Now I would definitely not use ruby 1.9.x in production but I sometimes do have to be able to run locally antique codebases that haven't been used in a long time. I was caught off guard because a simple install of an unrelated application with homebrew destroyed a big part of my work flow.
Macports never did this and kept libraries side by side cleanly.
Now, this is from the point of view of a software developer with a specific niche requirement. For normal users, from a security standpoint, it would most likely make sense to remove old versions of openssl.
Macports never did this and kept libraries side by side cleanly.
Now, this is from the point of view of a software developer with a specific niche requirement. For normal users, from a security standpoint, it would most likely make sense to remove old versions of openssl.
Why not just use rbenv with a $HOME/.gem directory. Much simpler as Ruby versions come with their own openssl.
I was using rbenv, but try installing an ancient version of ruby through rbenv, I have never been able to get it to work without having the existing openssl library in my system (not an issue with newer versions)
I think that's because rbenv only introduced bundling openssl libs at a certain point in its history so, yes, if you're going for a really old version fair point.
Don't have a ton of experience with either macports or homebrew but pretty much any package manager deals with running multiple different versions at the same time, or projects using different versions of the same dependency, without getting in your way. Biggest/most famous example I guess would be javascript/npm/npm inc registry.
Nope, completely different “package manager”. Homebrew and Mac ports are more similar to apt or yum or Pacman, and those often do not provide for running multiples of the same software except in specific edge cases where sauf software can be argued to be different from itself e.g. python2/3, they sort of things.
Probably comparing it to MacPorts, which does allow multiple versions of the same packages to be installed simultaneously.
Nix(OS)?
No. MacPorts is so much better nowadays.
In what way?
Dependency management in Homebrew is nothing short of primitive or broken...
Not to mention that the recommended way of installing certain packages changes seemingly randomly sometimes. Python, PHP, OpenJDK are ones that I've specifically had issues with. It starts with finding some random blog post on Google that differs from every other blog post on Google about how to accomplish the install. Then you spend a bit looking for other references to see if the one you're following is the new way or the old way that won't work right anymore.
I also very rarely update my Homebrew packages because there is no telling what will break half the time due to this.
And the fact that simply installing a package force updates every other package by default! I needed a single tiny utility while on a screen share recently, I `brew install` it. 15 minutes later Brew was still figuring the world out and it ended up being faster to just find the utility on Github and download it manually to use while letting Brew do its thing in the background. Still no idea if it ever ended up installing...
Don't get me wrong, I still think brew has been handy for me over the years. But I breathe a sigh of relief whenever I `apt-get` something on a Debian box and it behaves in a sane manner.
I also very rarely update my Homebrew packages because there is no telling what will break half the time due to this.
And the fact that simply installing a package force updates every other package by default! I needed a single tiny utility while on a screen share recently, I `brew install` it. 15 minutes later Brew was still figuring the world out and it ended up being faster to just find the utility on Github and download it manually to use while letting Brew do its thing in the background. Still no idea if it ever ended up installing...
Don't get me wrong, I still think brew has been handy for me over the years. But I breathe a sigh of relief whenever I `apt-get` something on a Debian box and it behaves in a sane manner.
Homebrew is what a package manager would look like if Apple was doing it.
So quite limited in scope and not much configurable options and if you say that you need some features, they'll tell you you're doing it wrong.
It is quite easy to install though and has a lot of packages but if you have specific needs that are unmet, you are on your own.
It's more of a update manager than a true package manager.
So quite limited in scope and not much configurable options and if you say that you need some features, they'll tell you you're doing it wrong.
It is quite easy to install though and has a lot of packages but if you have specific needs that are unmet, you are on your own.
It's more of a update manager than a true package manager.
I disagree. Apple would spend the time to make universal binaries work (unlike homebrew, who has stated they won't support them). Not installing universal binaries has some bad implications for Rosetta for developers. Having mixed single processor binaries in PATH can cause architectures to switch unexpectedly for subprocess chains (like when running a build tool), or even get "bad CPU type" errors in some contexts if the wrong arch is first in PATH.
Universal binaries matter most for closed source. With Homebrew being used for Open Source software it’s by far not a priority for the generic user.
The last years have shown clearly that Apple doesn’t go out of their way to make things easy for devs if it doesn’t helps their main client group.
The last years have shown clearly that Apple doesn’t go out of their way to make things easy for devs if it doesn’t helps their main client group.
No. This isn't fixed by open source. Open source projects also do binary releases (see brew cask), and those need to be universal as well. Someone needs to build those universal binaries, and homebrew has decided to be incapable as a platform to do that by refusing to ship universal binaries.
It is kinda mitigated for end users if you only run an x86 homebrew for the foreseeable future and never compile any software outside of homebrew, but that's a crappy answer.
Universal means you can seamlessly switch between architectures as necessary. Split arch homebrew, however, means you should probably keep one of them entirely out of your path until you need it, as your arch will silently change if you have the wrong arch bin in path (I encountered this in the wild). Having the wrong arch bin first in your path will also result in a bad cpu type error if you force arch on any parent process e.g. with arch -x86_64 (I encountered this in the wild).
Also, users expecting that their build tools will be x86 also results in hacks like checking the cpu type sysctl and forcing ARM, which in any build tool is likely to break the ability to build x86 binaries (I encountered this in the wild in several projects).
I've seen all of this in multiple open source projects. I had to stop using homebrew entirely for build tools as a result.
It is kinda mitigated for end users if you only run an x86 homebrew for the foreseeable future and never compile any software outside of homebrew, but that's a crappy answer.
Universal means you can seamlessly switch between architectures as necessary. Split arch homebrew, however, means you should probably keep one of them entirely out of your path until you need it, as your arch will silently change if you have the wrong arch bin in path (I encountered this in the wild). Having the wrong arch bin first in your path will also result in a bad cpu type error if you force arch on any parent process e.g. with arch -x86_64 (I encountered this in the wild).
Also, users expecting that their build tools will be x86 also results in hacks like checking the cpu type sysctl and forcing ARM, which in any build tool is likely to break the ability to build x86 binaries (I encountered this in the wild in several projects).
I've seen all of this in multiple open source projects. I had to stop using homebrew entirely for build tools as a result.
Cross-compiling is a need that almost no user ever has.
The only legit need on macOS was for a long time iOS only and now, the two supported CPU architectures. But that is covered by using XCode.
There would be now need for a Apple Homebrew to use or provide universal binaries.
Homebrew's design is for providing tools for the need of the single user of the system (it doesn't even work well in a multi-user environment) with the tools he needs on this system. Switching CPU architecture would be solved with reinstalling Homebrew on the new system (like it is now).
The only legit need on macOS was for a long time iOS only and now, the two supported CPU architectures. But that is covered by using XCode.
There would be now need for a Apple Homebrew to use or provide universal binaries.
Homebrew's design is for providing tools for the need of the single user of the system (it doesn't even work well in a multi-user environment) with the tools he needs on this system. Switching CPU architecture would be solved with reinstalling Homebrew on the new system (like it is now).
I just checked your profile and it seems like you're a command line software developer for Linux. I'm not sure why you're telling a Mac developer what Mac developers do and don't need, or what use cases are "legitimate".
I'm speaking from personal experience about what is broken about homebrew's developer tools for a software developer building and using lots of existing open source software for Mac. Please don't respond further unless you are absolutely confident your position is in good faith and supported by personal relevant experience.
I'm speaking from personal experience about what is broken about homebrew's developer tools for a software developer building and using lots of existing open source software for Mac. Please don't respond further unless you are absolutely confident your position is in good faith and supported by personal relevant experience.
Do you think command line software developing for Linux is a paid full time job? My day job is on macOS where I've been using Homebrew for about 7 years.
I know its warts. I don't say that it isn't broken for the usecase you are describing. I'm saying that like the Homebrew developers, if Apple were in charge of Homebrew, they wouldn't care about such a use case because it would only affect a tiny percentage of their user base.
If you don't believe that just look how old the user base command line tools are that are installed by default on macOS.
For example bash is "GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17), Copyright (C) 2007 Free Software Foundation, Inc." That's 14 years ago.
I know its warts. I don't say that it isn't broken for the usecase you are describing. I'm saying that like the Homebrew developers, if Apple were in charge of Homebrew, they wouldn't care about such a use case because it would only affect a tiny percentage of their user base.
If you don't believe that just look how old the user base command line tools are that are installed by default on macOS.
For example bash is "GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17), Copyright (C) 2007 Free Software Foundation, Inc." That's 14 years ago.
This is a software supply chain issue, but it likely doesn't interest Intel Mac users who are still using x86 homebrew and who can't empathize with the experience of the upstream developers for all the Mac software they use.
And MacPorts is what had/has Apple involvement actually.
And, it does in fact support universal binaries.
Seconded, port select is great as is port variant.
Thanks for doing homebrew -- been using it for years!
Seconded — it brought a huge improvement to the quality of life on a Mac. Thank you!
Appreciate the comment!
Brew is great. I’ve switched to using Nix as much as I could but most “Apps” aren’t supported yet where `brew install —cask` has it right away.
Always nice to know Brew will always have the latest version around. The only problem with that ends up being that if you use brew for development dependencies like Node or Python you can’t manage multiple versions. Nix being the most powerful in this area.
Always nice to know Brew will always have the latest version around. The only problem with that ends up being that if you use brew for development dependencies like Node or Python you can’t manage multiple versions. Nix being the most powerful in this area.
I've switched to Nix and never looked back, thanks to Homebrew embedding spyware into the package manager. I keep my non-system apps in ~/Applications and back them up with the rest of my files.
Recently made my first PR to nixpkgs. Definitely looking to see what it takes to manage more *.apps using only Nix.
Luckily this is much less of an issue on my NixOS desktop or EC2 instances.
Luckily this is much less of an issue on my NixOS desktop or EC2 instances.
> spyware
Please.
Please.
Apps that silently transmit your activity without consent are spyware. It's an objective evaluation.
What makes you think it happens silently or without your consent?
Silently: it does not print any indication it is transmitting activity data when it does so.
Without consent: it does so automatically, without prompting the user to opt-in to such spying.
Without consent: it does so automatically, without prompting the user to opt-in to such spying.
There is a prompt. It’s impossible to miss.
It is not a prompt; I encourage you to review it. It proceeds automatically.
It also only occurs once, on install, and is silent thereafter on each data exfiltration.
It also only occurs once, on install, and is silent thereafter on each data exfiltration.
> It is not a prompt; I encourage you to review it. It proceeds automatically.
It won’t start telemetry until the next invocation. It also clearly tells you the options you have.
That’s as prompt-y as it gets.
It won’t start telemetry until the next invocation. It also clearly tells you the options you have.
That’s as prompt-y as it gets.
If anyone from Homebrew is lurking on here. Thank you. I’m working with my management team to send a donation your way. We’ve been using it for IT and Engineering deployment builds for years and it’s something we feel we owe as a sign of gratitude and to keep the project running.
Thank you again!
Thank you again!
You’re welcome! Glad it’s useful to you. Appreciate your shout-out and donation!
/me searches changelog for "`brew update` now runs asynchronously and doesn't block the process to install a 3 year-old package." Dismayed, I do not find it.
Asynchronous formula updates would IMO save the most Mac man-years of almost any macOS tool.
Asynchronous formula updates would IMO save the most Mac man-years of almost any macOS tool.
I feel like it would be a /tremendous/ amount of work to install packages -- which often have dependencies -- asynchronously.
When is this really a problem, anyway? You should probably not have something like 'brew update' scheduled to run periodically, as then a broken package could break something unexpectedly. It should really only be run when you're ready to check for broken things, which means you can also schedule it to run when you can deal with waiting for the process to complete.
When is this really a problem, anyway? You should probably not have something like 'brew update' scheduled to run periodically, as then a broken package could break something unexpectedly. It should really only be run when you're ready to check for broken things, which means you can also schedule it to run when you can deal with waiting for the process to complete.
Homebrew now runs `brew update` before every `brew install`, no? That's how it gets in the way, you just wanted to install a thing, and now you are stuck waiting for `brew update` -- which I feel takes longer than it used to?
(You also may be confused between `brew update` and `brew upgrade`. I know I often am!)
(You also may be confused between `brew update` and `brew upgrade`. I know I often am!)
Running `brew install hello` triggers `brew update` automatically unless the environment variable HOMEBREW_NO_AUTO_UPDATE is set:
echo export HOMEBREW_NO_AUTO_UPDATE=1 >> $HOME/.zshrc
I do not think it was a wise decision to enable auto update on `brew install` as long time users expect `brew update` and `brew install` to be two separate steps (as it was for years) and because Homebrew no longer operates like `apt` and other package managers.
Looks like it was changed in 2016: https://github.com/Homebrew/brew/issues/288
echo export HOMEBREW_NO_AUTO_UPDATE=1 >> $HOME/.zshrc
I do not think it was a wise decision to enable auto update on `brew install` as long time users expect `brew update` and `brew install` to be two separate steps (as it was for years) and because Homebrew no longer operates like `apt` and other package managers.
Looks like it was changed in 2016: https://github.com/Homebrew/brew/issues/288
It makes sense semantically to me, and would be fine/preferable if `brew update` only took a few seconds to complete.
Cause otherwise I'm not necessarily going to remember to brew update ever, and am going to be getting old formulae. I think I'm not alone, I suspect this was done because too many users were never updating.
I am not super familair with how apt works, but I think the "workflows" of brew are already different than typical apt uses, with continuous incremental releases, and users expected to stay up to date with them -- things aren't necessarily going to keep working (installing properly) if you never run `brew update`, and I think many users were not.
I do want `brew install` to get me the latest formula for the thing I'm installing.
The problem is when it can add several minutes to a `brew install` invocation, interupting my ability to get on with my business.
But good to know about the env variable so at least I can choose which tradeoff I want!
Cause otherwise I'm not necessarily going to remember to brew update ever, and am going to be getting old formulae. I think I'm not alone, I suspect this was done because too many users were never updating.
I am not super familair with how apt works, but I think the "workflows" of brew are already different than typical apt uses, with continuous incremental releases, and users expected to stay up to date with them -- things aren't necessarily going to keep working (installing properly) if you never run `brew update`, and I think many users were not.
I do want `brew install` to get me the latest formula for the thing I'm installing.
The problem is when it can add several minutes to a `brew install` invocation, interupting my ability to get on with my business.
But good to know about the env variable so at least I can choose which tradeoff I want!
Then `HOMEBREW_NO_AUTO_UPDATE` is probably for you.
> If set, do not automatically update before running brew install, brew upgrade or brew tap.
> If set, do not automatically update before running brew install, brew upgrade or brew tap.
That’s what I did - I have `@daily brew update` in my crontab.
It’s possible to set `HOMEBREW_NO_AUTO_UPDATE` and `HOMEBREW_AUTO_UPDATE_SECS` to somewhat alleviate this.
https://docs.brew.sh/Manpage#environment
https://docs.brew.sh/Manpage#environment
Optimizations to brew would save many many watthours. If I were to guess, it would be over a MWh per year.
You can set up launchd to run `brew update` and `brew upgrade` regularly -- it's what I do.
Don't do this if you're attached to specific versions of any formulae you have installed. You can try `brew pin`ning them though.
Don't do this if you're attached to specific versions of any formulae you have installed. You can try `brew pin`ning them though.
How often are you running brew? Not using MacOS anymore, but I mostly did it when configuring the computer the first time, and maybe some more when changing projects. So like two times a year or so.
As someone who has used MacPorts for a long time (it started years before Homebrew was created), I wonder if anyone whose used both for a while can compare the two.
MacPorts has a "patch it to work with macOS" mentality that seemed much more needed in the early 00's when PowerPC/big-endian and other Mac or BSD specific differences were more common, whereas Homebrew tends to want everything to come unpatched from upstream, which does seem a bit cleaner.
I think I'm getting thrown off by stories like https://news.ycombinator.com/item?id=26017852 and horror stories about upgrades or migrations - I've been doing a 'port list requested > file', copying that file around, then 'port install `cat file`' to get the same setup on a new machine for quite a while.
MacPorts has a "patch it to work with macOS" mentality that seemed much more needed in the early 00's when PowerPC/big-endian and other Mac or BSD specific differences were more common, whereas Homebrew tends to want everything to come unpatched from upstream, which does seem a bit cleaner.
I think I'm getting thrown off by stories like https://news.ycombinator.com/item?id=26017852 and horror stories about upgrades or migrations - I've been doing a 'port list requested > file', copying that file around, then 'port install `cat file`' to get the same setup on a new machine for quite a while.
So glad I sponsor this project. The mac would be entirely harder to use as a development platform without these package managers (this praise includes all the efforts not just that of Homebrew). Donate here: https://github.com/homebrew/brew#donations
Note: I am not affiliated with the project in anyway other than being a backer and a user.
Note: I am not affiliated with the project in anyway other than being a backer and a user.
Thank you so much for your generous support and for the shout-out.
Much needed and appreciated. You rock!
I don't see Linux mentioned at all.
I'm not complaining, but as a Linux user who uses dnf/yum for everything there, but also has some needs for things that either aren't packaged at all, or are but move too slowly and break often (youtube-dl) I use brew. I love that it installs in my home directory. Linux Brew is awesome to have for that.
I don't expect Linux will ever be a prime focus, but I do wish it would be easier for packages to support Linux. Many times it doesn't require any actual formula changes beyond trivial.
Note: If you are on Arch, AUR is often better than home brew. I don't use Arch on my daily drivers/work machines anymore but deeply miss the AUR :-)
I'm not complaining, but as a Linux user who uses dnf/yum for everything there, but also has some needs for things that either aren't packaged at all, or are but move too slowly and break often (youtube-dl) I use brew. I love that it installs in my home directory. Linux Brew is awesome to have for that.
I don't expect Linux will ever be a prime focus, but I do wish it would be easier for packages to support Linux. Many times it doesn't require any actual formula changes beyond trivial.
Note: If you are on Arch, AUR is often better than home brew. I don't use Arch on my daily drivers/work machines anymore but deeply miss the AUR :-)
I didn't even know Homebrew worked on Linux!
> The new HOMEBREW_BOOTSNAP environment variable allows the use of the Bootsnap gem to speed up repeated brew calls
Very nice.. Can't wait to do the numbers on this!
Very nice.. Can't wait to do the numbers on this!
Homebrew is great!
I love it.
My only complaint is that I never remember 'brew upgrade' from my 'brew update'. which is which.
I love it.
My only complaint is that I never remember 'brew upgrade' from my 'brew update'. which is which.
[deleted]
Still love this tweet: https://twitter.com/mxcl/status/608682016205344768?lang=en
I personally found Homebrew to be really helpful when I looked at MacOS as a unix environment and tried to engage in local development as if it were a unix environment.
[Un]fortunately, I've stopped looking at MacOS in this way. I now look at MacOS as the better version of ChromeOS that runs on non-shit hardware (two time PixelBook owner, both of them had serious hardware issues, and getting support from Google for what they view as throwaway devices is not at the same level as the Apple Store/Genius Bar experience).
Taking the view that MacOS is a fat client for apps and browser use, that is capable of also running [Uni|linu]x VMs, and pushing myself to adopt the "local editor, remote runtime" working model, has been really liberating.
I now no longer look at Homebrew as necessary. Instead, I can use package managers built for operating systems that are intended to work with package managers and that whole ecosystem, rather than fighting against Apple's efforts to improve the local security environment.
In many ways, I feel like I've come full circle to where I was at in the mid-00's, working in a SaaS/enterprise environment developing on Windows using VMs for actual dev work so as to keep my local machine safe, healthy, and productive.
Rather than dealing with the annoyance of Docker for Mac, I can instead just work in a VM running normal docker, or one of the competing solutions, and this translates very closely to what I run if I'm working against a VM.
And if you are doing anything "serverless" or "server-light", it's even less helpful to try and continue working with the MacOS terminal userland.
So, hats off to homebrew for all they do, but I really think the puck is moving elsewhere and that's where I'm headed instead.
[Un]fortunately, I've stopped looking at MacOS in this way. I now look at MacOS as the better version of ChromeOS that runs on non-shit hardware (two time PixelBook owner, both of them had serious hardware issues, and getting support from Google for what they view as throwaway devices is not at the same level as the Apple Store/Genius Bar experience).
Taking the view that MacOS is a fat client for apps and browser use, that is capable of also running [Uni|linu]x VMs, and pushing myself to adopt the "local editor, remote runtime" working model, has been really liberating.
I now no longer look at Homebrew as necessary. Instead, I can use package managers built for operating systems that are intended to work with package managers and that whole ecosystem, rather than fighting against Apple's efforts to improve the local security environment.
In many ways, I feel like I've come full circle to where I was at in the mid-00's, working in a SaaS/enterprise environment developing on Windows using VMs for actual dev work so as to keep my local machine safe, healthy, and productive.
Rather than dealing with the annoyance of Docker for Mac, I can instead just work in a VM running normal docker, or one of the competing solutions, and this translates very closely to what I run if I'm working against a VM.
And if you are doing anything "serverless" or "server-light", it's even less helpful to try and continue working with the MacOS terminal userland.
So, hats off to homebrew for all they do, but I really think the puck is moving elsewhere and that's where I'm headed instead.
I agree with this.
I use homebrew on my personal machine mostly to get more modern versions of the terribly outdated commands that Apple ships but that's .. a small surface. I don't use it for anything really appropriate and would not.
Professionally - for people who build locally on the mac - the sheer awkwardness of pinning specific versions so all developers have a common environment regardless of install order or timeframe is quite painful with homebrew vs. apt.
I use homebrew on my personal machine mostly to get more modern versions of the terribly outdated commands that Apple ships but that's .. a small surface. I don't use it for anything really appropriate and would not.
Professionally - for people who build locally on the mac - the sheer awkwardness of pinning specific versions so all developers have a common environment regardless of install order or timeframe is quite painful with homebrew vs. apt.
I'm interested in this workflow, some questions:
- When you say "local editor, remote runtime", are you referring specifically to VS Code's remote development features?
- Is the remote runtime a Linux VM on the same machine, or running on another machine?
- Do you run git locally?
- Do tests run locally?
- Do you have a link to an article detailing this workflow?
- When you say "local editor, remote runtime", are you referring specifically to VS Code's remote development features?
- Is the remote runtime a Linux VM on the same machine, or running on another machine?
- Do you run git locally?
- Do tests run locally?
- Do you have a link to an article detailing this workflow?
There are a couple different ways to implement this type of workflow. You can use tools like VSCode's remote development features, you can use an IDE/editor with built-in rsync/sftp capabilities, you can also use git via a local command line (though that defeats the purpose), or a tool like Mountain Duck if you want to 100% eschew a CLI. Admittedly, for myself, I prefer to simply shell into a remote machine and use vim. But, that's "remote editor; remote runtime".
The remote runtime can be either a local Linux VM or a remote VM. That's kind of the beauty of this approach. You can generate a machine image and have a consistent environment either locally or remote, depending on your current needs. Obviously, when working with a local VM, you can use host mounted directories using one of the various tools for doing so, in a much more efficient manner.
I tend to not run git locally, but prefer to run it on my source on the remote environment. This is mostly because I'm not wanting to use the native Mac OS userland.
I do not run tests locally, that's very much the intention.
I don't have a link to an article handy. You already seem familiar with the VS Code tooling, so it's a good place to start.
I'm not a pedant about this. There are some rough edges, especially in the file sync'ing for the local editor, and integration with IDEs. But you can get most of the way there and be pretty happy.
edit...
When I was working on ChromeOS, the actual workflow was more like "host OS" -> "local VM" -> "remote VM". The Crostini environment itself runs in a local VM and container. So you would essentially be running an editor inside that local VM (I ran VSCode this way for a hot minute), and I was working with an sshfs mounted src directory from a remote VM. This was mostly because I was doing work against a dev environment that relied on a number of hosted services that were only accessible to the remote VM. The hoops we sometimes have to jump through...
The remote runtime can be either a local Linux VM or a remote VM. That's kind of the beauty of this approach. You can generate a machine image and have a consistent environment either locally or remote, depending on your current needs. Obviously, when working with a local VM, you can use host mounted directories using one of the various tools for doing so, in a much more efficient manner.
I tend to not run git locally, but prefer to run it on my source on the remote environment. This is mostly because I'm not wanting to use the native Mac OS userland.
I do not run tests locally, that's very much the intention.
I don't have a link to an article handy. You already seem familiar with the VS Code tooling, so it's a good place to start.
I'm not a pedant about this. There are some rough edges, especially in the file sync'ing for the local editor, and integration with IDEs. But you can get most of the way there and be pretty happy.
edit...
When I was working on ChromeOS, the actual workflow was more like "host OS" -> "local VM" -> "remote VM". The Crostini environment itself runs in a local VM and container. So you would essentially be running an editor inside that local VM (I ran VSCode this way for a hot minute), and I was working with an sshfs mounted src directory from a remote VM. This was mostly because I was doing work against a dev environment that relied on a number of hosted services that were only accessible to the remote VM. The hoops we sometimes have to jump through...
Thanks a lot for the details!
I'm definitely grateful that MacOS has a package manager at all. Mac before the unix-like OS X days was like using Windows: you had to hunt for installers or DMG's. Except Mac didn't have the legacy support that Windows aims for: all your programs would break when a major update like MacOS 8 came out.
The bigger pain point for me is macOS still has no system-wide registry of installed applications. You specifically need to keep the uninstaller around for big applications.
So lord help you if the app you want to delete isn't a single .app file in /Applications
So lord help you if the app you want to delete isn't a single .app file in /Applications
Homebrew helps you with that, even if the app was installed without Homebrew:
brew uninstall --zap --force CASKNAME
brew uninstall --zap --force CASKNAME
Not to be the eternally dissatisfied user, but I've never gotten homebrew to work properly on a machine with multiple users. It only works for 1 user at a time, even if it's owned by a user group that both users belong to.
Has anyone else had that problem or found a solution?
Has anyone else had that problem or found a solution?
Homebrew maintainer here. I do suffer from the multi-user problem myself, and happily work around it on my own Mac by maintaining a dedicated `brew` user, to which the actual users have passwordless sudo rights.
I’ve taken notes of my workaround, if it helps: https://gist.github.com/claui/ada85e696029cfa8cba9b91723ce2e...
I’ve taken notes of my workaround, if it helps: https://gist.github.com/claui/ada85e696029cfa8cba9b91723ce2e...
Interesting! Thank you!
Along with Hackbraten's answer — I don't know if this would be more or less work for you but would a per-user Homebrew installation help? I don't have any multi-user machines but for years I've kept my Homebrew installation in ~/Homebrew, where I have complete ownership of it. (Really you can install Homebrew in any directory) Or would the space/compilation cost be prohibitive?
Not a Homebrew maintainer, just a satisfied user.
Not a Homebrew maintainer, just a satisfied user.
On macOS, one major drawback is that if you use a non-standard installation directory for Homebrew, you can no longer install binary packages and everything is compiled from source.
If you can live with that, you should be fine though.
If you can live with that, you should be fine though.
Not anymore, right? I've noticed that recently, many formula which don't longer require `/usr/local` specifically actually install from bottles, which has been neat.
That’s correct. A major part of formulae is still not relocatable though.
To take a (lol) contrarian view compared to the rest of this thread, I think brew is great with the exception of the upgrade/update nonsense, which makes me utterly furious every time I try to update (or is it upgrade?) one of my brew-installed tools.
I realize this is a bit counter to the thread title but can someone who’s familiar with macports give their take on whether it’s worth using both brew + macports at once is a good idea?
I’ve been solely using brew and very much appreciate the convenience but I saw that macports allows multiple versions of a single package which has been a pretty big pain point for me with brew.
It doesn’t happen super often but there have been several times that this limitation for brew has been a huge pain point, forcing me to pollute things by compiling manually, putting it in a new location, etc.
I know it’s a bit far fetched but if my package manager could replace say, pyenv, by just making it easier to install several different versions and then letting me pick the default symlink, that would be so helpful (or even just not removing python2...).
I know it’s a bit far fetched but if my package manager could replace say, pyenv, by just making it easier to install several different versions and then letting me pick the default symlink, that would be so helpful (or even just not removing python2...).
Homebrew and MacPorts tend to not do well because Homebrew installs itself to /usr/local, which is on PATH by default and can cause strange build failures for other things. However, with the new prefix it might be possible to do this better now.
I will likely never move off 10.14 due to hardware and 32-bit software requirements. When will homebrew stop supporting this? I would have stayed on 10.12 but homebrew stopped working well on that after it became unsupported.
We typically support N-2, N-1 and N, which means you’ll be fine with Mojave until Big Sur’s successor comes out.
[deleted]
I wrote a post critical of Homebrew a few days ago, but it is a really great project.
I first used it 10 years ago when I was doing Rails development. It was kind of a pain to get everything setup on our development machines, installing new bits and making sure other bits were up to date.
After using brew it made our lives much easier. Combined with Rubygems it made every other platform and language look silly.
I first used it 10 years ago when I was doing Rails development. It was kind of a pain to get everything setup on our development machines, installing new bits and making sure other bits were up to date.
After using brew it made our lives much easier. Combined with Rubygems it made every other platform and language look silly.
Thanks all! Love Homebrew, keep up the good work!
I personally consider malware anything that I cannot install with homebrew.
Jokes aside, I've loved it for many years now. Thanks!
Jokes aside, I've loved it for many years now. Thanks!
Not really on-topic but am I the only one? I stopped developing locally, my notebook is just a thin client ssh'ing into a remote dev server. I get all amenities like developing on the production os, no awkward package managers, 1 GBit up and down—always and anywhere and Docker pushes within few seconds.
I never get people trying to set things up locally. You put stuff on a remote Linux server and the problems are instantly gone.
There are enough tools to work efficiently on a remote server and you can easily access what you do there from another machine.
There are enough tools to work efficiently on a remote server and you can easily access what you do there from another machine.
VSCode made all this so much more convenient.
Oh. Came here looking for some sweet technological enhancements to the making of beer at home...
I'm sure this is splendid
I'm sure this is splendid
I'm not familiar with Homebrew.
Is it the kind of thing I could use to manage packages in my own directory as a non-root user (on Linux)?
If so, will it be able to base itself on what my distribution offers, or will it build things up from scratch with its own toolchain packages?
Is it the kind of thing I could use to manage packages in my own directory as a non-root user (on Linux)?
If so, will it be able to base itself on what my distribution offers, or will it build things up from scratch with its own toolchain packages?
> Is it the kind of thing I could use to manage packages in my own directory as a non-root user (on Linux)?
Yes, exactly.
Not sure what exactly you mean with your second question though.
Yes, exactly.
Not sure what exactly you mean with your second question though.
I mean, will it try to use the libraries and toolchain components available on my system to build other packages which I download, or will it kind of bootstrap its own toolchain for building?
From https://docs.brew.sh/Homebrew-on-Linux:
> Homebrew does not use any libraries provided by your host system, except glibc and gcc if they are new enough.
> Homebrew does not use any libraries provided by your host system, except glibc and gcc if they are new enough.
I'm trying to avoid installing Rosetta 2. Anyone know if there's a way to configure Homebrew to never install an x86_64 binary and throw an error if I ask it to install a formula which isn't native on AArch64?
This is my experience with Homebrew. It'll give you a red error message if it needs Rosetta 2 prompting you to manually install it.
Isn't this just how it works already? If you install the native Apple Silicon version it seems like it either only downloads the pre-built Apple Silicon bottles (which now exist for most packages) or it builds from source. I do not think it ever downloads an x86_64 package in this mode. It was only when running Homebrew via Rosetta that this would happen.
BTW, I periodically check in Activity Monitor to see if any Intel binaries are running. The only one ever running for me so far is Signal. There is no reason to avoid Rosetta though. It is already installed and works pretty seamlessly and effectively.
BTW, I periodically check in Activity Monitor to see if any Intel binaries are running. The only one ever running for me so far is Signal. There is no reason to avoid Rosetta though. It is already installed and works pretty seamlessly and effectively.
This is great! Does anyone happen to know how to upgrade from the experimental Apple Silicon version (installed to an alternate prefix /opt/homebrew) that was released late last year?
It still use the /opt/homebrew for silicon bottle — so no change. I think `brew upgrade`will do the trick in fact !
But does it still try to update literally every time you use it?
That has changed recently: https://github.com/Homebrew/brew/issues/10386
If you set HOMEBREW_NO_AUTO_UPDATE to 1, it won't update when you run the install, upgrade, and tap commands like it normally does
Also don't forget HOMEBREW_NO_ANALYTICS=1 in your environment to keep it from silently phoning home a machine-specific unique identifier and your client IP (city-level geolocation) to Google every time you run it.
https://github.com/Homebrew/brew/issues/142
https://github.com/Homebrew/brew/issues/142
Thank you, Homebrew maintainers, for all your hard work. One of the very first things I've done on new computers is install Homebrew, couldn't live without it :)
If you wish to donate, then you can do the creator a favor:
https://mxcl.dev/#donate
Without taking away from Max Howell, he hasn’t been with Homebrew for years. Anyone is still free to donate to him (naturally), but those will have no impact on Homebrew. To donate to Homebrew, see https://github.com/Homebrew/brew#donations
Great point, thanks!
Missing: How do I upgrade?
So they're just not going to fix the /opt /usr/local split? Real dick move.
I am fascinated by the polarizing nature of Homebrew on HN. I've used both MacPorts and Homebrew, and I think the only reason I switched to Homebrew years ago was that Homebrew didn't try to install stuff at a system level, which felt more in line with a package manager that wasn't integrated into the OS.
But I'm sure MacPorts is fine still. Why are people so strongly opinionated about this, particularly on the pro-MacPorts side? Nothing I've seen in the comments so far jumps out as an obvious source of the passion.
But I'm sure MacPorts is fine still. Why are people so strongly opinionated about this, particularly on the pro-MacPorts side? Nothing I've seen in the comments so far jumps out as an obvious source of the passion.
People are strongly opinionated about everything if the internet forums are any indication. I think the truth is more like opinionated people speak up, and most people just enjoy life.
I wasn't even aware it was polarizing. Have enjoyed using it for the past 6 years and never thought much about it. The comments of "it sux", "worst thing ever" feel very petulant.
Love that i can install/update the packages i might need and get on with my day.
Love that i can install/update the packages i might need and get on with my day.
It's ideology. They're both fine at what they do at this point, and you really only need to choose based on what has the packages you need.
For reference, I use MacPorts. I often tell new users to just use Homebrew. It really just doesn't matter.
For reference, I use MacPorts. I often tell new users to just use Homebrew. It really just doesn't matter.
this should just become the default package manager on all linux distros.
What will we do if apple restricts the installation to only signed apps and brew no longer works?
> Particular thanks on Homebrew 3.0.0 go to MacStadium and Apple for providing us with a lot of Apple Silicon hardware and Cassidy from Apple for helping us in many ways with this migration.
Apple has made it clear that they’re not interested in doing that. I believe them (for now).
[deleted]
As much as I sympathize (deeply) with all the criticism of Homebrew here on this thread -- I used to use MacPorts religiously and love it -- I don't think Homebrew took the field purely through sneaky marketing or n00b decisions alone. They leveraged the momentum of a lot of new devs coming to OS X and provided an easier path for people wanting to help out.
I hate to say it, but if this was a race (?), Homebrew won. Thankfully we all still have the choice to use MacPorts if we want, but there's no point in being mean about Homebrew at this point either.