361–370 of 403 posts
Is it still slow?
`brew` has never been slow for me. (Subjective, obv.)
I've never gotten this complaint about Brew at all. It has never seemed notably slow to me.
Earlier quoted context omitted.
This is a lesson about mental models. From the brew devs' point of view it doesn't make sense because they are different commands. From the end user's point of view it makes perfect sense because brew is just a tool to install shit with and they do not wish to expend any brain cycles on it. That includes remembering whether this particular tool calls it update or upgrade. You know the second point of view is right be…
Disagree. I've been a user for a lot of years and prefer the apt-like distinction between the commands. They do different things. > Similarly, as someone who only rarely uses it, a huge frustration is that when I do, it invariably wants to update 100+ packages. I never asked for it to do that and I was happy with whatever was installed right before it decided to do that and block my system for 20 minutes. There's a s…
Bad interfaces require you to care about implementation details that are arbitrary. Like whether the index is local or remote, whether it is stale or fresh, etc.
This is not an opinion, this is what decades of product design lessons tell us.
I don't use brew enough to ever go dig into settings, I wouldn't even know where to go find them, nor do I wish to expend cycles to go find them. They shouldn't design their software with such shitty defaults. All they're doing is ensuring my opinion of it gets worse every time I use it.
Earlier quoted context omitted.
Disagree. I've been a user for a lot of years and prefer the apt-like distinction between the commands. They do different things. > Similarly, as someone who only rarely uses it, a huge frustration is that when I do, it invariably wants to update 100+ packages. I never asked for it to do that and I was happy with whatever was installed right before it decided to do that and block my system for 20 minutes. There's a s…
Good interfaces have 1 to 1 mappings between the available levers and the user's model of the tasks they wish and need to perform. Bad interfaces require you to care about implementation details that are arbitrary. Like whether the index is local or remote, whether it is stale or fresh, etc. This is not an opinion, this is what decades of product design lessons tell us. I don't use brew enough to ever go dig into set…
It already does. Sometimes I want to update. Sometimes I want to upgrade. This model matches the models of the other package managers I've used, for the most part.
> I don't use brew enough to ever go dig into settings, I wouldn't even know where to go find them, nor do I wish to expend cycles to go find them. They shouldn't design their software with such shitty defaults.
That's fine—but I guess it's not a huge frustration, then.
Earlier quoted context omitted.
Good interfaces have 1 to 1 mappings between the available levers and the user's model of the tasks they wish and need to perform. Bad interfaces require you to care about implementation details that are arbitrary. Like whether the index is local or remote, whether it is stale or fresh, etc. This is not an opinion, this is what decades of product design lessons tell us. I don't use brew enough to ever go dig into set…
> Good interfaces have 1 to 1 mappings between the available levers and the user's model of the tasks they wish and need to perform. It already does. Sometimes I want to update. Sometimes I want to upgrade. This model matches the models of the other package managers I've used, for the most part. > I don't use brew enough to ever go dig into settings, I wouldn't even know where to go find them, nor do I wish to expend…
As for your mental model, you've adapted to the implementation details of specific package managers. This is just Stockholm lite.
Yikes! This no longer shows the new formulae and casks - I've used Homebrew as a discovery tool, now I need to watch the git commits [0]! [0]: https://github.com/search?q=repo%3AHomebrew%2Fhomebrew-core+...
Subscribe to the commits with an RSS reader: https://github.com/Homebrew/homebrew-core/commits/master.ato...
I despise, despise, Homebrew's "we know better than you" approach to always installing the latest versions of every dependency. How tf is this fine? They don't even offer alternative. They just say "we can't test all of the packages installed and all version combinations, so this is the best we can do". Well, no one asked you to test my exact setup. All I'm asking for is: if I have perfectly working Node 18 and I nee…
You didn't install "Node 18", you installed "Node". If you want Node 18, grab the "node@18" package instead of "node". This is how Brew has managed this problem for years: problematic dependencies that need to be pinned to specific versions are given specific packages.
Is it still slow?
Earlier quoted context omitted.
`brew` has never been slow for me. (Subjective, obv.)
I've heavily used probably four Linux package managers, plus both major ones on Mac, and have used two or three less-common Linux package managers at least a little bit, plus a couple of the BSDs. Oh, and Chocolatey on Windows. I've never gotten this complaint about Brew at all. It has never seemed notably slow to me.
Earlier quoted context omitted.
The problem is that every time you install something it will update a gazillion dependencies because there is a minor version difference in a library I don't even use. And of course I did not ask for those binaries to be upgraded. When I do a yum install, 99% of the cases it just add the package I need. And won't mess with my dev tools.
I believe you need to set the envvar HOMEBREW_NO_AUTO_UPDATE to avoid that problem.
Yikes! This no longer shows the new formulae and casks - I've used Homebrew as a discovery tool, now I need to watch the git commits [0]! [0]: https://github.com/search?q=repo%3AHomebrew%2Fhomebrew-core+...