Kinda off topic, but when I see a project or an article use brew on Linux instead of their native package manager or something like flatpak I generally assume the author has very limited knowledge about Linux and I can ignore this project/article.
Our audit of Homebrew
181–190 of 205 posts
Re: Our audit of Homebrew
#182Kinda off topic, but when I see a project or an article use brew on Linux instead of their native package manager or something like flatpak I generally assume the author has very limited knowledge about Linux and I can ignore this project/article.
Even though Homebrew isn’t meant as a replacement for the system package manager, there are legitimate use cases.
For example, if you’re on Debian but need a newer version of just one tool, it makes absolute sense to install Homebrew alongside. It’s designed to play well with the system package manager, uses its own separate prefix so it won’t cause shared libs confusion, and only shadows the packages you install with it. Nothing wrong with that inherently, and certainly not a sign of limited knowledge.
Re: Our audit of Homebrew
#183Earlier quoted context omitted.
Apple would certainly favor macports over that rubbish ruby thing. Ports are from FreeBSD, MacOS is from FreeBSD.
That is provably false from so many angles. * Apple has no aversion to Ruby, and on the contrary has multiple developers pushing for it. They themselves had MacRuby, a project that allowed one to create Mac OS X (at the time) applications with Ruby.¹ * The reason there’s even an Xcode command line tools package available officially from Apple is because of Homebrew. A third-party made it first by extracting the neces…
Wrong. MacPorts started as official DarwinPorts, supported by Apple. It became independent later. It is a proper ports package manager.
Homebrew would have a good head start, because it can use a better language, ruby. But it blew its chances with many questionable choices, they are just amateurs. But as always, worse is better.
Re: Our audit of Homebrew
#184I’m still good on MacPorts. Seems I’m alone these days. Works fine for me.
I'm still sour that homebrew gained so many user when it was started by basically FUD-ing Macports and arguing that their ability to reuse the existing toolchain of OSX with the superior choice while Macports pointed out that homebrew design was flawed.
Fast forward to now, Homebrew actually had to make all the changes Macports pointed out as flawed design decisions because, well, they were but enjoy more users and has tainted Macports reputation. It's very much a case of the inferior product winning as far as I'm concerned. I know that most of the original team is not there anymore but I still mostly refuse to use it.
Re: Our audit of Homebrew
#185Earlier quoted context omitted.
Funny that you mention it, I also went Homebrew -> MacPorts -> Nix. Homebrew had analytics and broke versions too often. MacPorts is way more stable, but some niche packages would not build well, and I had terminfo issues with tmux. Nix allows me to override most of that, and I can share home manager config with my Debian workstation.
For the life of me, I will never understand how developers, of all people, see “just take ownership of system directories, which we will relentlessly pollute” as acceptable behavior for homebrew. Flabbergasted.
The really shameful behaviour at the time was that if you changed it (which you theorically could), some packages were so poorly written than they just broke and homebrew just warned you it was going to be this way instead of actually fixing the issue.
Re: Our audit of Homebrew
#186Kinda off topic, but when I see a project or an article use brew on Linux instead of their native package manager or something like flatpak I generally assume the author has very limited knowledge about Linux and I can ignore this project/article.
Even though Homebrew isn’t meant as a replacement for the system package manager, there are legitimate use cases. For example, if you’re on Debian but need a newer version of just one tool, it makes absolute sense to install Homebrew alongside. It’s designed to play well with the system package manager, uses its own separate prefix so it won’t cause shared libs confusion, and only shadows the packages you install wit…
I don't see that. Brew on Linux is a copy of dito on osx which itself was inspired by Linux package managers.
Instead of using the real deal, people generally suggest Brew because that's what they are familiar with from osx.
If you need bleeding edge of something (and don't want to build from source) we got things like flatpak, appimage directly from developers or AUR and nix and other stuff.
I'm yet to find someone proposing brew over the rest because of some new package genuinely being available only on brew only.
Re: Our audit of Homebrew
#187Earlier quoted context omitted.
Even though Homebrew isn’t meant as a replacement for the system package manager, there are legitimate use cases. For example, if you’re on Debian but need a newer version of just one tool, it makes absolute sense to install Homebrew alongside. It’s designed to play well with the system package manager, uses its own separate prefix so it won’t cause shared libs confusion, and only shadows the packages you install wit…
I don't see that. Brew on Linux is a copy of dito on osx which itself was inspired by Linux package managers. Instead of using the real deal, people generally suggest Brew because that's what they are familiar with from osx. If you need bleeding edge of something (and don't want to build from source) we got things like flatpak, appimage directly from developers or AUR and nix and other stuff. I'm yet to find someone…
> we got things like flatpak, appimage directly from developers
Some people prefer timely, high-quality, well-tested bugfixes and security updates for the underlying low-level dependencies of an app.
An upstream app developer is much less likely to provide an updated flatpak mere minutes after e.g. a critical OpenSSH security fix comes out of embargo. Distro maintainers on the other hand, such as the Homebrew core maintainers, can do that. They also have security audits, see TFA, and established processes. Nothing wrong with that at all.
> and nix
That just comes down to personal preference. Some people like Nix due to the amazing level of isolation it provides, and that’s perfectly fine. Some prefer Homebrew instead because it’s easy to use and respects the FHS.
All the things we’ve discussed so far are highly subjective, come down to personal preference, and say absolutely nothing about how skilled a user is.
Re: Our audit of Homebrew
#188Earlier quoted context omitted.
I don't see that. Brew on Linux is a copy of dito on osx which itself was inspired by Linux package managers. Instead of using the real deal, people generally suggest Brew because that's what they are familiar with from osx. If you need bleeding edge of something (and don't want to build from source) we got things like flatpak, appimage directly from developers or AUR and nix and other stuff. I'm yet to find someone…
> we got things like flatpak, appimage directly from developers Some people prefer timely, high-quality, well-tested bugfixes and security updates for the underlying low-level dependencies of an app. An upstream app developer is much less likely to provide an updated flatpak mere minutes after e.g. a critical OpenSSH security fix comes out of embargo. Distro maintainers on the other hand, such as the Homebrew core ma…
Core system package managers (apt etc) handle security issues quickly and in collaboration with security researchers and authorities. They have far more manpower, experience and connections than brew.
Bleeding edge is handled by rolling package managers, and these often build automatically from source as soon as a commit is tagged.
I don't see a clear reason to use brew, which does everything a little bit worse. In fact, I see it as a red flag in projects since it usually indicates lack of first class Linux support.
Re: Our audit of Homebrew
#189I’m a bit puzzled by the wording of this blog post, because it says you’ve worked with Homebrew to do this audit, but your name sounds familiar to me, and indeed if we check Homebrew’s README [1]: > Homebrew's maintainers are […long list of names…] William Woodruff […] [1]: https://github.com/Homebrew/brew Is there any reason this is not mentioned in the blog post? I don’t think it would make a difference, but just t…
I wasn’t a maintainer at the time I did the audit :-). I’ve been a non-maintaining “member” of the project for a long time, which is the pseudo-emeritus position we give to previous maintainers who want to continue participating in internal conversations and governance. I was then offered membership again, months after the audit, due to some unrelated work on Homebrew that didn’t exist and wasn’t planned before the a…
Why, oh why....are TL;DR's at the end of articles/ comments?
Re: Our audit of Homebrew
#190Earlier quoted context omitted.
1Password and docker desktop are two good test subjects. 1Password especially is the one I mentioned above as being a problem child in general with nix setups on Mac VScode in particular was the one that broke for me, though that is actually available and mostly functional in nixpkgs so that one is not a showstopper.but might be a good test case to repro
I just tried 1Password and it refused to start not being in `/Applications`. I've seen this happen with one other app (Secretive), although it doesn't quite refuse to run. I can't remember all the details, but I think it has to do with a limitation in newer versions of macOS, where apps that try to register launchd services can only do so if they live in /Applications rather than ~/Applications. The problem with laun…
As for your first question, about why 1Password refuses to run outside of Applications, I’m pretty sure it’s security. There is something special about Applications on MacOS that apparently AgileBits views as an attack vector when run outside of it.
I was curious about your final question as well, but I know little about how this works. The error when I tried vscode looked to be that the signature had gotten malformed somehow during brew-nix’s copy operation but since I had no idea what a correct signature should even look like I got stumped there.