> 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...
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.
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.
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.
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!)
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.
The nodes that used to build High Sierra bottles have been re-commissioned to build Big Sur bottles.
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).
I used to use Fink and MacPorts for MacOS package management, but brew was so easy to use that it won me over.
All the other languages I use support binary libraries on their package managers.
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.
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.
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.
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.
[1]: https://lna7n.org/2020/01/06/pulling-the-plug-on-archmac.htm...
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.
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.
If Mac Ports requires that level of knowledge to be user friendly it’s no surprise they lost.
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.
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.
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 ...
It was a great learning experience nearly 20 years ago.
It's just not for you.
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.
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.
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.
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.