211–220 of 301 posts
But the amount of overreach in gatekeeper to try and make the failed Mac App Store profitable and milk $90 a year at the expense of apps users want to run is egregious.
Homebrew is not really pro in any way: they force updates, deprecate old software that is still widely in use, the maintainers are always very combative and dont allow any discussions or other opinions. In the end it's a package manager for consumers that hand holds you and is not really useful in a pro context. I've been meaning to jump to macports anyway, maybe ill do it now...
Huh, I guess I didn't use it in a "pro" context for 14 years then? Must have imagined that.
Earlier quoted context omitted.
Reading that discussion, I was very surprised at MikeMcQuaid’s reaction to xtqqczze’s concerns, which were calm, brief, and valid. In response, Mike was a dick. Maybe it’s totally understandable that being a maintainer for the biggest mac package manager conditions a knee-jerk asshole response in a person.
There's a misunderstanding here what the issue tracker is for in Homebrew. In some projects, it's for free-for-all discussion. That's great if those projects want to use it that way. In this issue's case, you have someone in leadership (p-linnane) communicating that work needs to be done, a maintainer (carlocab) communicating what needs to be done to make this change. xtqqczze's attempt to get us to move backwards on…
You could have just said this (maybe you did when linking the code of conduct) instead of writing a paragraph of confrontational arguments and it would have looked way better imho.
> You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.
If this was true every oss project would either be dead or be entirely comprised of dicks, neither of which are the case.
Earlier quoted context omitted.
Apple Silicon cannot boot Windows ARM and Apple is dropping boot camp support alongside x86 support in the near future.
> Apple Silicon cannot boot Windows ARM That's totally up to Microsoft… they could done a licensing deal with Apple years ago to enable Windows ARM to run natively on Apple Silicon hardware.
Earlier quoted context omitted.
Reading that discussion, I was very surprised at MikeMcQuaid’s reaction to xtqqczze’s concerns, which were calm, brief, and valid. In response, Mike was a dick. Maybe it’s totally understandable that being a maintainer for the biggest mac package manager conditions a knee-jerk asshole response in a person.
There's a misunderstanding here what the issue tracker is for in Homebrew. In some projects, it's for free-for-all discussion. That's great if those projects want to use it that way. In this issue's case, you have someone in leadership (p-linnane) communicating that work needs to be done, a maintainer (carlocab) communicating what needs to be done to make this change. xtqqczze's attempt to get us to move backwards on…
your explanation did nothing to speak to being a dick, did not attempt to apologize, only tried to justify the poor behavior.
Earlier quoted context omitted.
> by the time my M1 macBook Air gets slow enough to annoy me (maybe a year or two from now?) It should be good for at least 5 years from now, if not more.
Probably not if you bought the 8GB version :D
Earlier quoted context omitted.
> by the time my M1 macBook Air gets slow enough to annoy me (maybe a year or two from now?) It should be good for at least 5 years from now, if not more.
Before macOS 26 I would have agreed with you. But after Tahoe my M1 MacBook Pro feels a lot slower. Funny, there's even some regression in layer backed NSView rendering where the app I'm working on is faster (in some aspects) in a macOS 15 VM than on bare metal under macOS 26.
https://furbo.org/2025/10/06/tahoe-electron-detector/
I've got a couple things that I use which aren't yet up-to-date, and are blocking my upgrade.
I don't understand what this means, although I've read the whole thread. Does this mean people won't be able to use Homebrew to compile software from source (and run it)? Does it mean that they'll be able to use Homebrew to compile software from source, but not download prebuilt binaries (and run them)? Does it mean that they'll be able to download prebuilt binaries, but only run them if they're built by a developer…
I don't know either (right now). They closed the discussion, so they don't want people to talk about it. Perhaps someone with more information will chime in, who isn't a homebrew maintainer.
> Our issue trackers (other projects may differ) are used to track the work for maintainers or soliciting community contributions. They do not exist for people to debate the merits of decisions already made. We have Homebrew/discussions (and, well, the rest of the internet) for that.
They just don't want discussion about the merits of a settled decision to interfere with their work tracking when they provide a perfectly good discussion forum[1] for that.
Earlier quoted context omitted.
brew install php@X.Y doesn’t work for you? Although I should say that I haven’t tried to go back many major versions, I wonder if they provide 7.x for example.
It works until PHP officially EOLs the version. Then brew stops supporting it and you have to install some finicky 3rd party taps/repos to get the older versions. A huge pain... In the real world there are still apps running PHP 7.4 and even older!
Homebrew not allowing users to install EOL versions of software with no security patches or updates is a _good_ idea. Just because a fraction of a tiny minority needs some ancient version of PHP doesn't make it a good idea.