The only reason it did work was because you did an upgrade. I was also on the betas. As an experiment, I backed up my Homebrew install and tried one from scratch. Failed badly. Very important things like gnu-readline would not compile. I couldn't even get as far as nvim.
Packaging work was already being done under 2.1 to fix what was broken, and Catalina bottles were already appearing.
By the time Catalina final came out, it was usable from scratch, but only if you had homebrew installed under /usr/local so you could rely on the aforementioned bottles.
I was using an alternative prefix of /opt/homebrew. (I have been for years). When I attempted to continue using that, a few packages for which there were Catalina bottles would not compile, and so could not be installed under /opt/homebrew. I finally gave up, and started from scratch under /usr/local.
I REALLY don't like how homebrew insists on /usr/local for stability. The whole "do yourself a favor" mentality speaks to something broken in their packaging methodology. Any package should be able to be compiled under any prefix. And for the most part they can be, except for the exceptions that the core team or package maintainer doesn't care about because "you were warned."
I wouldn't mind using /usr/local were it not for the fact that lots of other installers want to put stuff there, and it can cause conflicts. Keeping homebrew in an isolated prefix makes a lot more sense. /usr/local was and remains a poor choice.
==> Homebrew has enabled anonymous aggregate formulae and cask analytics.
Read the analytics documentation (and how to opt-out) here:
https://docs.brew.sh/Analytics
Opt-out analytics capture? A bit of a shame it's not opt-in.
It's opt-in because you don't have to use brew if you don't want to. It helps the devs do their jobs better (a job they do for free), and it is a free tool someone is under no obligation to use.
Please don’t subvert the meaning of “opt-in” like this; also, mentioning “free” does not give you a pass to shut down any complaints about the software. To address your other points: I disagree that opt-in analytics necessarily help.
We can disagree on both points. I'm making the effort to defend people who do real work (brew devs) vs an entitled vocal minority. Time is the ultimate non-renewable resource, and it shouldn't be wasted by grandstanders.
User hostile patterns should be raised and addressed. This is not user hostile in my opinion (considering the very little data collected, and the efforts to anonymize), it is plainly obvious what data is collected, you can observe what data will be sent, you can opt out of data collection (which the devs find of value), and you can choose not to use the software.
It has clearly not had an impact on usage of the tool:
The Homebrew maintainers do real work, but I disagree with your characterization of this complaint as “entitled” and coming from time-wasting “grandstanders”. I’d be happy to hear how you disagree but trivializing the issue doesn’t really help :(
I think we've reached an impasse. Fundamentally, it's brew's project, not the user's, and my opinion is that the brew project has met the burden of attempting to balance their needs (data collection) with those of their users (privacy). It is very easy to dictate a mandate when it's not your time. Compromise is necessary, inevitable even.
> "grandstanders"
If someone would like to donate your time, effort, and funds to standing up analytics infra solely for Brew's use (or perhaps in aggregate for a group of OSS projects) so that they could avoid communicating with Google infra, I fully support such efforts. Historically, I have not seen this occur when a group takes issues with activities of an open and/or free project and the project has offered to accept the necessary resources from those who desired to be stakeholders via their input.
I actually chose to stop using the project and contribute to another one because I felt that I could not align my values with Homebrew’s and they did not seem to be willing to compromise on this and other concerns that had been brought up. (With this specific issue, the “opt-out” part is more important to me than the “Google” one, so a self-hosted analytics solution would only be somewhat effective in alleviating my concerns.)
It could cure cancer; it is still done without consent of the user whose computer it runs on, which is unethical. It violates their privacy, which is an abuse of their human rights.
You should not make software that abuses the human rights of your users.
If you bought a plain old alarm clock and it silently connected to wi-fi and told the manufacturer every time you were in the room with it via a motion sensor, without notifying you when it did so or asking you if you want that, you would call that a defective product, and you would say that the front of the box, that says nothing about being a tracking device, is fraudulent.
It’s the same with a package manager, or any other software tool. Tracking in this way without consent is not acceptable, even if there is some fine print on the back of the box that tells you about it.
in your .bashrc or similar prior to installing homebrew, otherwise it phones home during install before you can run the analytics off command. Do not use or recommend the analytics off command; homebrew will still spy on you before you get a chance to use it.
The claim that it is anonymous is also a lie: your IP address is transmitted alongside the data to Google, who absolutely knows who that IP address belongs to. Additionally, homebrew generates a unique tracking identifier on install, to track you across IP addresses (so Google receives your travel history, too). It is absolutely not anonymous.
This sort of nonconsensual tracking is deeply unethical, and the developers of this software should be ashamed of the fact that they are making spyware.
Can this collected data be de-anonymized and cause serious privacy leaks? If not, I’d help the devs ship a better product - it’s the least I can do other than contributing code.
Reinforcing the sentiment that this decision should be in the hands of the user, especially considering the first part of the question is not an easy one to answer.
The problem of Homebrew is the language it's written in. Porting it into something native and faster, maybe Go, maybe Rust - will make the user experience way better.
It seems like the team has made significant improvements in speed even without changing the language Homebrew was written in; I’m sure there’s still more low-hanging fruit they can pick before having to make such a large change.
I've been using Homebrew for years and I've never felt negatively about the user experience, I find it easier to use than yum for example. What do you think can be improved?
Would it, though? Almost all the time during installation is spent downloading and extracting the tarballs and running compilers if necessary. Even updating Brew itself is almost all git.
Ruby is not the problem at all. The vast majority of time with homebrew is spent doing git operations, downloading tarballs, running makefiles, and the like. You could rewrite the entire thing in Rust and not notice any difference.
The thing that might make a difference is to build some custom infrastructure, so that `brew update` didn't have to do a `git fetch` every time, but instead downloaded the updated formula registry in a more efficient manner. But that's a lot to ask of a project like this.
> The thing that might make a difference is to build some custom infrastructure, so that `brew update` didn't have to do a `git fetch` every time, but instead downloaded the updated formula registry in a more efficient manner. But that's a lot to ask of a project like this.
How would this impact privacy? If I do brew search, does that impact privacy?
Homebrew stores a lot of information in the Git repository that it really doesn’t need. A simple list of packages would work with the search feature and probably be faster to work with.
The bigger problem with Homebrew IMO is that it does not follow the proper UNIX way to install packages - works for a single-user setup, but not for a multi-user one.
I don't see that as much of a problem. The vast majority of Macbooks are going to be single user machines anyway. If you really need multi-user support, multiple users on one machine can always install brew to their home directory (https://andrewjorgensen.com/post/install-homebrew-to-your-ho... for info)
I really wish more release documentation pointed you to how to perform that upgrade. This page, the front page, nor the installation pages show up to upgrade.
No, it isn't "hard" to figure out, and I personally know how to do it, but for newer users it puts up a barrier to entry.
While Homebrew is perhaps technically crude and somewhat inflexible compared to other and older package managers, I think it deserves real credit for being so easy to add packages to. I contributed Homebrew packages after a few weeks of using macOS, while I didn't contribute a single package in the ten years I ran Debian.
I'm also impressed by the focus of the maintainers and their willingness (really, enthusiasm) for saying no and cutting features. We need more of that in the programming field. Homebrew is unashamedly solely for running the standard configuration of the newest version of well-behaved programs, which covers at least 90% of my use cases. I use Nix when I want something complicated or nonstandard.
(Incidentally, I also contributed Nix derivations after only a few weeks of running NixOS, so Homebrew is not the only good package manager.)
What are some 'Nix derivations'? I hate to say it, but I haven't heard of any, let alone used any.
edit: I guess I know lots: snappy, dpkg, apk-tools, etc... I somehow think of brew as different from this list though. I find myself often wishing that brew worked on linux.
3. there are very powerful hooks to allow you to easily customize derivations by various means (look at some more complex derivation, like php, which defines dozens of options and there are other mechanisms as well).
1. Brew also has, but not 2 or 3 (it's definitely more customizable than say debian packages, but much less so than nix)
> I'm also impressed by the focus of the maintainers and their willingness (really, enthusiasm) for saying no and cutting features. We need more of that in the programming field. Homebrew is unashamedly solely for running the standard configuration of the newest version of well-behaved programs, which covers at least 90% of my use cases. I use Nix when I want something complicated or nonstandard.
I wish I could say I've had better experiences as a result of this attitude.
The problem is the assumption that the latest software will always be an improvement, and not introduce any new problems, which is simply not true, especially on OSX.
OSX has become really unstable over the last few years. If you use your computer to make money, then it is in your best interest to stay at least a version behind, and do your homework before any major OS update. Obviously, you should still stay current with security updates.
I think I could have been forgiven for not wanting to update to High Sierra when there were severe issues with graphics card drivers, data corruption, and anyone could log as root without a password. Not wanting to use the latest version of OSX is not an edge case.
So Brew constantly nudging me to roll the dice and update is really unhelpful. Brew itself has broken on updates more times than I can count. I don't see why it even bothers to do things like tell you that a package you want was removed, without offering an easy way to install it. It has gotten so bad that I have had to write helper scripts just to make it usable.
Homebrew is built on the assumption that you should always be running the latest version of homebrew and the latest version of all the packages you've installed. If something doesn't work, you're forced to update everything to the latest versions and hope that fixes things.
In general I don't like this constant pressure to abandon old versions of things, it doesn't really benefit anyone. A fragmented world is a decentralized world.
I agree, but it reduces the scope of the project incredibly. Freeing up resources that can be spent elsewhere. Much like how Homebrew doesn't seem to support multiple users on the same box. It addresses 80-90% of people's need.
I feel like it is less necessary for a user-land package manger like Homebrew, but doesn't Arch Linux and Gentoo do the same thing with the whole OS? I've heard of issues, but in general people seem ok with it.
Personally, I've looked to Nix, but went back to Homebrew it after having trouble with the UI, lack of packages, and learning curve of contributing my own packages. I'm hoping to try again sometime.
I'm just glad Mac OS X 10.13 High Sierra and above are still fully supported since I have a computer which is stuck on that release (incompatible with 10.14).
Homebrew + Caskroom has made my zero touch deployments flawless. A little bash, some DEPNotify, a rock solid MDM, and Apple’s DEP, I can ship a Mac to any employee in the world and have them boot the computer, create their local account, and all of the latest third party apps get installed automatically.
Ten years ago this would have taken a lot of engineering. Today it’s just bash calling Homebrew to do the heavy lifting.
51 comments
[ 2.4 ms ] story [ 267 ms ] threadEdit: Found it. I didn't see I could click it. https://github.com/Homebrew/homebrew-core/issues/44988
Packaging work was already being done under 2.1 to fix what was broken, and Catalina bottles were already appearing.
By the time Catalina final came out, it was usable from scratch, but only if you had homebrew installed under /usr/local so you could rely on the aforementioned bottles.
I was using an alternative prefix of /opt/homebrew. (I have been for years). When I attempted to continue using that, a few packages for which there were Catalina bottles would not compile, and so could not be installed under /opt/homebrew. I finally gave up, and started from scratch under /usr/local.
I REALLY don't like how homebrew insists on /usr/local for stability. The whole "do yourself a favor" mentality speaks to something broken in their packaging methodology. Any package should be able to be compiled under any prefix. And for the most part they can be, except for the exceptions that the core team or package maintainer doesn't care about because "you were warned."
I wouldn't mind using /usr/local were it not for the fact that lots of other installers want to put stuff there, and it can cause conflicts. Keeping homebrew in an isolated prefix makes a lot more sense. /usr/local was and remains a poor choice.
The fix is to run:
Previous discussion: https://news.ycombinator.com/item?id=11566720
User hostile patterns should be raised and addressed. This is not user hostile in my opinion (considering the very little data collected, and the efforts to anonymize), it is plainly obvious what data is collected, you can observe what data will be sent, you can opt out of data collection (which the devs find of value), and you can choose not to use the software.
It has clearly not had an impact on usage of the tool:
https://formulae.brew.sh/analytics/os-version/365d/
I think we've reached an impasse. Fundamentally, it's brew's project, not the user's, and my opinion is that the brew project has met the burden of attempting to balance their needs (data collection) with those of their users (privacy). It is very easy to dictate a mandate when it's not your time. Compromise is necessary, inevitable even.
> "grandstanders"
If someone would like to donate your time, effort, and funds to standing up analytics infra solely for Brew's use (or perhaps in aggregate for a group of OSS projects) so that they could avoid communicating with Google infra, I fully support such efforts. Historically, I have not seen this occur when a group takes issues with activities of an open and/or free project and the project has offered to accept the necessary resources from those who desired to be stakeholders via their input.
You should not make software that abuses the human rights of your users.
If you bought a plain old alarm clock and it silently connected to wi-fi and told the manufacturer every time you were in the room with it via a motion sensor, without notifying you when it did so or asking you if you want that, you would call that a defective product, and you would say that the front of the box, that says nothing about being a tracking device, is fraudulent.
It’s the same with a package manager, or any other software tool. Tracking in this way without consent is not acceptable, even if there is some fine print on the back of the box that tells you about it.
The claim that it is anonymous is also a lie: your IP address is transmitted alongside the data to Google, who absolutely knows who that IP address belongs to. Additionally, homebrew generates a unique tracking identifier on install, to track you across IP addresses (so Google receives your travel history, too). It is absolutely not anonymous.
This sort of nonconsensual tracking is deeply unethical, and the developers of this software should be ashamed of the fact that they are making spyware.
Reinforcing the sentiment that this decision should be in the hands of the user, especially considering the first part of the question is not an easy one to answer.
The thing that might make a difference is to build some custom infrastructure, so that `brew update` didn't have to do a `git fetch` every time, but instead downloaded the updated formula registry in a more efficient manner. But that's a lot to ask of a project like this.
How would this impact privacy? If I do brew search, does that impact privacy?
No, it isn't "hard" to figure out, and I personally know how to do it, but for newer users it puts up a barrier to entry.
I'm also impressed by the focus of the maintainers and their willingness (really, enthusiasm) for saying no and cutting features. We need more of that in the programming field. Homebrew is unashamedly solely for running the standard configuration of the newest version of well-behaved programs, which covers at least 90% of my use cases. I use Nix when I want something complicated or nonstandard.
(Incidentally, I also contributed Nix derivations after only a few weeks of running NixOS, so Homebrew is not the only good package manager.)
edit: I guess I know lots: snappy, dpkg, apk-tools, etc... I somehow think of brew as different from this list though. I find myself often wishing that brew worked on linux.
https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...
Maybe the three most noteworthy things are:
1. it's not hard to write your own nix expression
2. you get a reproducible build
3. there are very powerful hooks to allow you to easily customize derivations by various means (look at some more complex derivation, like php, which defines dozens of options and there are other mechanisms as well).
1. Brew also has, but not 2 or 3 (it's definitely more customizable than say debian packages, but much less so than nix)
I wish I could say I've had better experiences as a result of this attitude. The problem is the assumption that the latest software will always be an improvement, and not introduce any new problems, which is simply not true, especially on OSX.
OSX has become really unstable over the last few years. If you use your computer to make money, then it is in your best interest to stay at least a version behind, and do your homework before any major OS update. Obviously, you should still stay current with security updates.
I think I could have been forgiven for not wanting to update to High Sierra when there were severe issues with graphics card drivers, data corruption, and anyone could log as root without a password. Not wanting to use the latest version of OSX is not an edge case.
So Brew constantly nudging me to roll the dice and update is really unhelpful. Brew itself has broken on updates more times than I can count. I don't see why it even bothers to do things like tell you that a package you want was removed, without offering an easy way to install it. It has gotten so bad that I have had to write helper scripts just to make it usable.
In general I don't like this constant pressure to abandon old versions of things, it doesn't really benefit anyone. A fragmented world is a decentralized world.
I feel like it is less necessary for a user-land package manger like Homebrew, but doesn't Arch Linux and Gentoo do the same thing with the whole OS? I've heard of issues, but in general people seem ok with it.
Personally, I've looked to Nix, but went back to Homebrew it after having trouble with the UI, lack of packages, and learning curve of contributing my own packages. I'm hoping to try again sometime.
> brew cat sets bat as pager if HOMEBREW_BAT is set
And bat is really a nice alternative to cat.
Ten years ago this would have taken a lot of engineering. Today it’s just bash calling Homebrew to do the heavy lifting.