141–150 of 156 posts
Earlier quoted context omitted.
Heyyyy, who are you to tell us what is and isn't compatible with homebrew? (Just kidding, thank you for creating homebrew and your continued work on it!)
I think Max Howell created Homebrew. I think McQuaid is the current maintainer
Earlier quoted context omitted.
Thank you, his arguments totally makes sense, only the part that makes me icky is: > There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks. People are free and probably do this because it is slow. Alternatives often are not a bad thing.
Indeed, everyone's free to do what they want, that's the beauty of open source. I have zero issues with people vibe coding alternative Homebrew frontends, it's good for the ecosystem for there to be more experimentation. What I take objection to is when one or more of these happen: - incorrect compatibility claims are made (e.g. if you're not running Ruby, no post-install blocks in formulae are gonna work) - syntheti…
Earlier quoted context omitted.
But you can turn that behavior off, IIRC it tells you the environment variable to set if you don’t want it to do that every time it runs. I agree it’s annoying, but I haven’t turned it off because it’s only annoying because I’m not keeping my computer (brew packages) up-to-date normally (aka, it’s my own fault).
I'd be much happier if it were on a background job, than arbitrarily running when I invoke a command
This feels like a solution looking for a problem. I have a couple hundred brew packages on my system and I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update. I’m sure the Homebrew folks could mine this for a few ideas of how to further optimize brew, but I don’t think I’ll be adopting it anytime soon. Compatibility is more important than speed in this case.
However, this is a vibe-coded app, with around 30 commits per day, which I don't let install packages on my machine.
Earlier quoted context omitted.
To upgrade my packages? I'm not sure I understand the question. That's how I use pretty much all of my systems that have package managers.
But why do you want daily upgrades? Most of us want to wait a little while for the bugs to be worked out of fresh releases. And hey, if everything is working today... why would I want to risk potential breaking changes?
This is not something that's solved by updating less frequently though. It would be solved by a 'minimum age' setting, but `brew` aren't planning on implementing that, with arguably valid reasoning: https://github.com/Homebrew/brew/issues/21421
Earlier quoted context omitted.
But why do you want daily upgrades? Most of us want to wait a little while for the bugs to be worked out of fresh releases. And hey, if everything is working today... why would I want to risk potential breaking changes?
> Most of us want to wait a little while for the bugs to be worked out of fresh releases. This is not something that's solved by updating less frequently though. It would be solved by a 'minimum age' setting, but `brew` aren't planning on implementing that, with arguably valid reasoning: https://github.com/Homebrew/brew/issues/21421
Minimum age solves a related problem - it gives maintainers some margin of time in which to discover vulnerabilities and yank the affected versions.
However, minimum age also delays you getting bug fixes (since those also need to age out).
In an ideal world one would probably be able to configure a minimum-age-or-subsequent-patch-count rule. i.e. don't adopt new major/minor package versions until either 1 month has elapsed, or a minimum of 2 patch versions have been released for that version.
If it doesn’t ever execute Ruby: it cannot be compatible with Homebrew. “Compatible” is doing a bit of work here when it also means “implicitly relies on Homebrew’s CDN, CI, packaging infrastructure and maintainers who keep all this running”. There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks. Homebrew is working on an official Rust frontend that will actually hav…
Earlier quoted context omitted.
To be fair, Apple stopped providing security fixes for Mojave ~4+ years ago, and there have been 7 or 8 new os releases since then… I don’t think it’s reasonable to expect an open source project to support everything
I think MacPorts still supports PowerPC Macs. I would need to rebuild my G5 to verify it because the hard disk is long dead, but last time I checked, it worked. I get it - it’s a different beast with very different ideas behind it, but MacPorts is BSD-solid, and that’s a lot.
MacPorts has some level of support for PowerPC, but anything that isn't in the most recent ~3-4 releases is likely to be cut off from any number of packages at useful versions. (There's substantial work down to support Rust on much older versions of macOS, but there's also versions above which Rust has cut off older macOS versions.)
I believe that there's a recommended stream for when you need older versions support, but it's definitely a secondary target from what I've been reading on the MLs.
If it doesn’t ever execute Ruby: it cannot be compatible with Homebrew. “Compatible” is doing a bit of work here when it also means “implicitly relies on Homebrew’s CDN, CI, packaging infrastructure and maintainers who keep all this running”. There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks. Homebrew is working on an official Rust frontend that will actually hav…
If it doesn’t ever execute Ruby: it cannot be compatible with Homebrew. “Compatible” is doing a bit of work here when it also means “implicitly relies on Homebrew’s CDN, CI, packaging infrastructure and maintainers who keep all this running”. There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks. Homebrew is working on an official Rust frontend that will actually hav…