Homebrew 2.2
brew.sh
brew.sh
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.)
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.
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)
==> Homebrew has enabled anonymous aggregate formulae and cask analytics.
Read the analytics documentation (and how to opt-out) here:
https://docs.brew.sh/Analytics
The fix is to run:
brew analytics offPrevious 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:
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.
export HOMEBREW_NO_ANALYTICS=1
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.
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.
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.
Edit: Found it. I didn't see I could click it. https://github.com/Homebrew/homebrew-core/issues/44988
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.
> 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.
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?