Hacker News Reader

Comment by mikemcquaid | Hacker News Reader

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).

View on HN

Literally just upgraded before seeing this post; I had 31 outdated packages and the first thing I saw was how blazing fast it was! I looked online to see if something changed and saw this post.

Speed was my biggest complaint about brew, so I'm glad to cross that one off my list of things I don't like about brew.

Thank you for your hard work BTW, brew's been a lifesaver on macOS and immutable distros.

Glad to hear it. A lot of time and energy has gone into performance work so glad that’s noticeable! Thanks for the kid words too <3

It is Rust now?

It's still in ruby, although I see the new GUI is in swift: https://github.com/homebrew

Rewriting a program in Rust (specifically) really only makes sense for a few reasons:

1) the existing implementation is in an unsafe, cumbersome language (C, C++).

2) the existing implementation language is too slow and that slowness cannot be worked around.

3) the implementation is enormous, in a dynamic language and you desperately need stricter types. But this doesn't really favor Rust specifically.

1 doesn't apply because Ruby is garbage collected. It's doubtful 2 applies just given what homebrew does: the long pole is always going to be I/O. The performance improvements in version 7 seem to mostly be due to doing more concurrently. I highly doubt the Ruby-ness gets meaningfully in the way.

I was kinda kidding because parent called it "blazing" fast lol. I didn't think it was Rust. Blazing fast software is reserved as a descriptor for Rust programs :)

i just tested and `mise bootstrap` is over twice as fast at installing when a bottle was in the cache. other commands like `status/check` are 20-30x faster. that's without spending much work at all on perf—i'm sure i could bring these numbers down much further.

Thank you for Linux Homebrew! It works so damn well.

For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.

Where do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?

> Where do you draw the line between system packages and user facing apps?

If it works in Homebrew, I almost always pick Homebrew. :) I have a pretty good feeling for what works since for the past few years I've mostly used an atomic distro (Aurora, based on Universal Blue, based on Fedora). It just comes naturally for me on Fedora too.

I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.

> I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.

Digression, but I’m curious since you brought it up: Are you saying that Silverblue-based distros are noticeably more stable than Fedora? Or is it more a theoretical benefit, that you believe more in the long-term stability of that architecture?

> Are you saying that Silverblue-based distros are noticeably more stable than Fedora?

TBH, I can only say it's far more stable than openSUSE, Ubuntu and Manjaro which are the non-atomic distros I've used for a long time.

Aurora has never broken and I've never had any major problems that I can recall in over two years. I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing).

It's Linux for those who have work to do and don't want to be a sysadmin for their desktop.

Thanks for the input!

> I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing).

Two follow-up questions on this:

- How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.)

- Does Aurora sometimes reboot multiple times when doing updates? On normal Fedora I usually end up running dnf update manually to avoid doing updates in batches; when it updates on reboot, it can reboot 2-4 times… I have full-disk encryption on my laptop and it’s painful to have to wait for all the password prompts during updates. If this could happen be done in one reboot on atomic distros that would certainly be a benefit.

> How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.)

I don't know, and I don't want to have know, how it works. :) It just does. You can force updates by running "ujust update". It updates Homebrew, Flatpaks, the system image and all Distroboxes in one go. You can also turn auto updates off.

> Does Aurora sometimes reboot multiple times when doing updates?

I doesn't reboot at all. I never notice updates, they happen in the background. System image upgrades are applied that time I turn off my computer and turn it on again. No extra reboots then. It's just a boot like any other.

Unless doing something esoteric like updating firmware that requires manual intervention, Fedora Atomic distros should never need to reboot multiple times to update, as updates are staged as side-by-side replacements of the entire base system, which includes essentially everything that would be installed through the system package manager in a traditional distro, so it's effectively like booting into an upgrade install of the OS (so preserving configuration files, user data, containers Flatpaks, etc.), except the old version remains available as a bootable option (which is possible because the atomic distros carefully separate OS and user directories, with the former typically mounted read-only).

The only times I've (very rarely) run into trouble is when adding additional RPMs to the base install, which, while frowned upon for this reason, generally poses no more problems than installing the same packages in a traditional Fedora installation, so worst-case you can simply uninstall the layered packages and re-run the update if something isn't working.

Again, without a reboot, because incompatible updates generally while staging, not after rebooting the system into the new OS, e.g., a package, possibly from an external repo, which does not exist, or depends on packages that do not exist, in the version you're updating to.

Aside from major version upgrades where packages you've layered might simply have been removed, this occasionally happens if you're installing packages from an external repo like RPM Fusion that's closely integrated with the base OS, because there are times when the base image (or even loose package mirrors) might lag a bit behind released loose packages which updates of external packages may depend on, and while you can override base image packages to resolve this, it's a bit of a hassle and probably not worth the trouble vs simply waiting until the base image catches up. Unless you have specific needs that can't be resolved by, e.g., running applications that require proprietary video codecs as Flatpaks or in containers, I'd recommend sidestepping this whole mess by not layering anything from RPM Fusion or similar (layering to pick up third-party packages that don't depend on very specific versions of distro packages works fine).

Generally speaking, nothing in the update / RPM install / RPM uninstall process touches the running OS unless you specifically request that it does, and nothing changes the on-disk copy of the running OS period. So, e.g., you can add new RPMs to the running install without rebooting, but how this works is that it first adds them to a new staged install, then creates transient filesystem overlays to activate the packages within the running OS. In other words, the on-disk copy of the current running OS remains unchanged and available in case anything goes wrong.

It's an interesting question on Linux. On macOS entire toolchains would be fair game. I just ran `brew install colima`, `brew install llvm`, etc.

But clearly anything that would conflict with distro-specific opinionated decisions is out. Or DE-specific opinionated decisions. Maybe a good rule is "anything that would be useful simutaneously on all *nix".

"Conflict" is maybe a strong word? Homebrew installs stuff into its own directory tree so it should in theory not have issues coexisting with native packages.

I use `lima` and `llvm` every day with brew. It works great there's no reason to use distro specific tooling when you can use what everyone else is using.

I don't understand the distinction you use here.

Then again I use versioned AppDirs on Linux since +20 years anyway, so I am not really into any arbitrary disctinction random linux distributions try to push down onto the (downstream) userbase. Besides, if you compile from source, why would you want to rely on the distribution package manager to begin with?

None of them allow for versioned AppDirs by default as far as I know; NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course), but as far as I know if you are on e. g. a debian system, you can not use it for a versioned AppDir layout.

> NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course)

Also Guix, which is inspired by Nix. Don’t know about AppDir support, though. Are AppDirs more of a general concept or a formalised standard? In what capacity are you using them?

for reference: https://docs.appimage.org/reference/appdir.html

> I don't understand the distinction you use here.

Distinction: https://news.ycombinator.com/item?id=49683258

I use "dnf" to upgrade my system and "flatpak update" and "brew upgrade" to upgrade the apps I've installed.

An app like VirtualBox does not install using Flatpak or Homebrew, so I would use dnf for that. It's usually an app or two that doesn't work via Flatpak/Homebrew/AppImage that I need to install using dnf.

On Linux I use mise to install CLI tools

Same, for me it made it possible for me to work on Linux with teammates on Mac with very little messing around of the setup scripts.

I don't know what I would do without brew on my Macs. Thank you and everyone who contributes!

Silly question - but how do you apply the cooldown to brew itself ?

I would think this is one of the most critical dependency that you would not want to get right away at let it rest for a couple of days

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.

Congrats and thank you to you and your team for maintaining critical infrastructure we all take for granted.

I think at one point you said you’re working on a rust rewrite? Is that still in the cards?

https://fishshell.com/blog/rustport/

Fish 4.0: The Fish of Theseus (fishshell.com)

906 points by jdxcode on Dec 28, 2024 | hide | past | favorite | 198 comments

https://news.ycombinator.com/item?id=42535217

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 reasons why Gradle is moving away from Groovy. I suspect that the number of people that use and know Groovy is steadily declining. Declarative Gradle, which is the future, is not Turing complete.

I can't help but notice the parallels between Gradle / Groovy and Homebrew / Ruby: using a dynamically typed Ruby DSL with Turing completeness like the olden Gradle ways, and Ruby is declining in popularity like Groovy.

I would have to imagine at some point, the people who know Ruby well enough to create / debug formulae will dwindle. What are the plans?

> I suspect that the number of people that use and know Groovy is steadily declining

One big surprise for me at a genomics/bioinformatics company was that of the three main technologies for orchestating bioinformatics workflows, Snakemake, Cromwell, and Nextflow, Nextflow was in a language based on Groovy. It took me back.

Except ~nobody uses declarative gradle in production yet, and groovy is mostly declining in favour of also turing complete Kotlin. It's yet to be discovered how declarative gradle fares and how much of imperative glue real-life projects will need

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.

They experimented with it but ultimately decided to focus on perf with their existing ruby codebase.

https://github.com/Homebrew/brew/issues/7755#issuecomment-51...

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.

Looks cool! Building.

`The macOS deployment target is set to 27.0, but the range of supported ....`

Golden Gate AAAAAARRRGGGHHHHHH

Just another few days, right? :)

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

Was issue with upgrade running out of disk space fixed?

Reply on news.ycombinator.com