mikemcquaid

Homebrew is heavily sandboxed and has been using the macOS sandbox for the best part of a decade, long before many other package managers did.

We also offer a .pkg installer and other installation options so curl | bash not needed for install that either.

After digging in pretty hard to AI development tools, I couldn't find any that worked quite how I want. Instead: a native SwiftUI app to work exactly how I want (and a bonus calendar full-screen notification app).

`brew install agentide minmaxcal` if you want to try either out.

Happy to answer any questions here!

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.

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.

Fixed and in 7.0.1.

Yes. If/when it doesn’t: it’s a bug and we’ll fix it. We can’t fix things people don’t report. Also: this is open source: you also could choose to fix it. Unsurprisingly the Homebrew maintainers do not spend a lot of their time uninstalling Homebrew.

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 I bother sometimes.

Linux Homebrew users would disagree.

Supporting macOS Intel has been significantly harder, slower and more expensive for us the last few years than adding ARM Linux support. If it was easy and free we’d have kept it for longer (until Apple and GitHub killed theirs at least which is coming in less than a year).

For initial installation to the default prefix someone needs to create the home directory and that person is probably root.

We hope to allow all prefixes under 64 bytes in future.

I didn’t build it. The emoji were my idea. I (and Homebrew) have used them heavily before LLMs did. Maybe LLMs loving them is my fault. Sorry if so.

This is a bug, sorry. Working on it.

Yup! We’ve been using it for a really long time at this point.

Were using Bubblewrap on Linux and moved to Landlock this release.

P.S. HUGE fan of your blog and writing Simon, keep up the great work. It’s the #1 resource I recommend to anyone in the industry wanting to learn more about LLMs (and pelicans).

You can’t, by design. We instead apply if for you on upstream packages from NPM, PyPi, etc.

Our model is very different to those where cooldowns exist and make sense. As-is if would just delay security updates too.