Live data from Hacker News

Homebrew 7.0.0

brew.sh

201–210 of 271 posts

Re: Homebrew 7.0.0

#201

Earlier quoted context omitted.

We've all gone through it :-( Happy users of the (really good) software until our hardware gets "too old" and the inevitable rug pull.

Uncompensated volunteers dropping support for a 7 year old device that is shortly going to be unsupported by the manufacturer isn't a rug pull. Entitlement can be wild, volunteers are volunteers. Consumers of volunteer output are free to support their use cases themselves on their own time. Find an ARM Mac used (like an M1) and upgrade.

> Find an ARM Mac used (like an M1) and upgrade.

And throw away perfectly good hardware.

Re: Homebrew 7.0.0

#202

Awesome, I just checked and had already upgraded at some point. I run the alias command below every now and then which keeps everything up to date. alias u="brew update && brew upgrade --greedy -y && brew upgrade --cask -y && brew cleanup"

Interesting. I use `--greedy` for casks but not regular formulae.

Re: Homebrew 7.0.0

#203

Earlier quoted context omitted.

An LLM helped with the initial tedium of rewording 1000s of PRs from maintainer centric language into user centric language. It was reviewed and edited (by a human) probably >20 times. Go look at the PR if you don’t believe me. I used to do these all by hand and they took me multiple hours. I still probably spent over an hour, including a bunch of time on a family holiday today. Comments like this make me wonder why…

Does it surprise you that people are getting more skeptical when the software that installs system packages is getting more and more generated by AI?

We have a Landlock (formerly Bubblewrap) Linux sandbox due to an LLM. It sat unfixed on our roadmap for almost a decade. I and at least one other maintainer (as well as several LLMs) reviewed every line of code.

Homebrew has never been better performant, secure, tested, linted and typed. I understand the LLM dubiousness (I used to share it myself) but we’re the type of project where it’s very easy to get agents to do sensible end-to-end testing and review a nice language (Ruby). Just us on our outputs, not just our inputs.

One of our former maintainers was in high school when working on Homebrew. I’m sure many people would have found that worrying. His code was great, though (I reviewed most of it) and he made the project better. Same ultimately with LLMs. Your mileage may vary.

Re: Homebrew 7.0.0

#204

Earlier quoted context omitted.

I tried it. It ended up being slower on most non-synthetic benchmarks (like repeatedly installing the same thing with warm caches). The lessons learned were instead used to make the Ruby frontend much faster.

I don't know anything about homebrew, but have a question ... I see some parallels between homebrew and Gradle ... for the longest time Gradle was using Groovy for build scripts. The Gradle / Groovy build script DSL was a little too magic and dynamically typed. It looked cute, but led to issues in developer UX (awful stack traces), tooling (documentation and autocomplete), robustness, and performance. There are other…

Ultimately you don’t need to know much Ruby to maintain or contribute to Homebrew. Ruby makes it very easy to write custom DSLs that don’t feel like Ruby. I didn’t really know any before working on Homebrew and it’s now my primary language.

That said, yes we have already moved away from our DSL being Turing Complete. This release drops for official taps the ability for packages to run arbitrary postinstall/uninstall/etc. Ruby in favour of DSLs and our JSON API.

This will likely get extended over time to eventually allow package definitions to themselves be in JSON.

Re: Homebrew 7.0.0

#205

Earlier quoted context omitted.

Uncompensated volunteers dropping support for a 7 year old device that is shortly going to be unsupported by the manufacturer isn't a rug pull. Entitlement can be wild, volunteers are volunteers. Consumers of volunteer output are free to support their use cases themselves on their own time. Find an ARM Mac used (like an M1) and upgrade.

> Find an ARM Mac used (like an M1) and upgrade. And throw away perfectly good hardware.

If it no longer is supported by software, it’s no longer perfectly good. Certainly, if you want to spend your time on supporting unsupported hardware based on personal belief, that’s a choice, and it’s your time. Compare to the cost of replacing the hardware. Time is not free, it is the ultimate non renewable resource. We are all slowly dying one day at a time, is that how you want to spend your time?

Recycle old gear when the math no longer maths and move on.

Re: Homebrew 7.0.0

#206

Earlier quoted context omitted.

6 years is really not a long time at all. You can probably find heaps of open source software out there that compiles and runs perfectly on 20 year old PCs. It's not like the maintainer has to do much to retain support--they just have to not make the software dependent on new operating systems. Bits don't rot.

How many of those 20 year old projects had to go through an architecture change that the manufacturer no longs supports? Come on man be reasonable.

Homebrew doesn't have to lift a finger to support Intel Macs. It already does! All they have to do is not kill support for them.

Hey, it's their software, they are all volunteers and can do whatever they want. I'm grateful for the short window of time in which I was able to use their software. I don't get to decide their support period, but I will still hopelessly complain about it. "Deliberately breaking compatibility with a computer because it is old" is my biggest axe to grind with the whole software industry, and I'll shake my fists at this cloud until I die.

Re: Homebrew 7.0.0

#207

Earlier quoted context omitted.

We've all gone through it :-( Happy users of the (really good) software until our hardware gets "too old" and the inevitable rug pull.

Uncompensated volunteers dropping support for a 7 year old device that is shortly going to be unsupported by the manufacturer isn't a rug pull. Entitlement can be wild, volunteers are volunteers. Consumers of volunteer output are free to support their use cases themselves on their own time. Find an ARM Mac used (like an M1) and upgrade.

As I replied in another comment[1], it's their software, their choice. Homebrew devs are doing the volunteer work, so they get to decide the support period and when to pull the rug out. I'll still shake my fists about it, because it's personally my biggest problem with the entire software industry's attitude, not just open source.

1: https://news.ycombinator.com/item?id=49687331

Re: Homebrew 7.0.0

#209
post #78

Earlier quoted context omitted.

would you please share what amount of the new dev (work done on brew) is AI/LLM-assisted. this major version bump was very quick to arrive compared to when v6 got released?

Can’t speak for others but a lot of my work. I review it all locally first. The flow feels a lot like reviewing human PRs locally. https://github.com/MikeMcQuaid/AgentIDE I actually wrote my own “Agent IDE” to make this prompt/review/push flow easier.

Thank you, very insightful. TBH, expected an actual flow of nonsense and suspicion meanwhile, but a daly later there is still none, perhaps the general sentiment already shifted enough. It also confirms the notion that the credibility of the author is more important than the credibility of the means to develop. Also, of course, we're all going to move to newer brew sooner or later, so this all effort is much appreciated.

Re: Homebrew 7.0.0

#210

Today, I’m proud to announce Homebrew 7.0.0. The most significant changes since 6.0.0 are faster installations and upgrades, stronger sandboxing, a native macOS app, built-in vulnerability checks and an advisory database, the end of macOS 10.15 support and Intel Macs moving to Tier 3 (announced last year).

Definitely notice the speed increase. Thank you for Homebrew. It's one thing that makes macOS bearable.
Post reply on HN