Homebrew 7.0.0
brew.sh635 points by mikemcquaid 3 days ago
635 points by mikemcquaid 3 days ago
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).
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".
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.
"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.
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 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?
> 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.
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?
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?
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.
> 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
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
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.
TIL Homebrew has its own sandbox mechanism - looks like it's built around their own sandbox-exec wrapper, at least on macOS: https://github.com/Homebrew/brew/blob/d79ef822ab8136e393ed5f...
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).
I found that Mise handles all my needs for development and it is scoped so it doesn't try to update Python and break all my virtual env when I install something new /shrug
Why would you even use python without uv anymore, and have a system python binary and virtual envs linked to it?
> Why would you even use python without uv anymore
Probably wouldn't:
https://mise.jdx.dev/mise-cookbook/python.html#mise-uv
> have a system python binary and virtual envs linked to it
I'm not sure if you're saying avoid using system python?
In my experience so far, you never want to develop complex software locked to system versions of runtimes. Too often you need a bleeding edge feature, or conversely need to postpone updating due to needing an old version for some reason.
Old Mise user too.
Now that PNPM supports managing runtimes [0], I found that most of Mise's offerings are actually built into package managers. Maybe I will have it graduates from my machine when I have time.
That's the beauty of asdf and then mise; they leverage existing solutions where possible, and unify how to get versioned runtimes for projects. Rust? rustup with mise, ruby? Precompiled when possible, otherwise ruby-build. Etc.
I'm not sure if I trust or want pnpm to support bundling rust for binary plugins, or various sundry toolchains.
But use what works for you.
> I'm not sure if you're saying avoid using system python?
That's what I'm saying, yes. System python should be treated as a REPL for interactive shell scripting and otherwise ignored entirely.
Python might be just one of the languages required by the dev stack not the only language. Mise is the right tool for the job.
True, but Python is the one with an env management system (virtual environments) which is the most prone to breakage for projects that depend on system Python.
Uv is far superior to both Mise and Homebrew for Python work, and I find that it removes the vast majority of pain preventing me from using Homebrew by default for most things, and Mise only occasionally for specific dev envs. Mise is a great tool though!
Last time I checked, Mise is still a one-man show. That’s way too risky for a critical party of my supply chain for my taste.
this makes no sense to me, the reason i don't give anyone else the commit bit is only to _protect_ the supply chain. you should want as few people with that access as possible.
I think the concern is more if something happens to you or stop development for any reason, then the project is dead or would fork in a few separate directions
do you have any kind of succession plan in place in case you get incapacitated for one reason or another? anyone you trust enough for that?
Yes I have a friend that can access my GitHub if I were to die and he would be in charge of deciding who would lead the project
So is sudo... And that's not "too risky" for the entire industry.
That's not to say bus factor is irrelevant (I personally think about it a lot when choosing software projects), but truthfully the bus factor here especially doesn't matter much, as mise is an easy tool to replace (with asdf, for example) if something goes wrong with it eventually.
I highly recommend trying it out. I resisted using it for some time, but it solved some pain points I had with NodeJS, Ruby, and Python regarding installation.
> So is sudo... And that's not "too risky" for the entire industry.
Sure it is, and that's why I'm looking forward to systemd's Run0 -- but for now, there's just no way around the sudo package. That's different for Mise, though, because there are a lot of ways to work productively without it. I'm not fond of consciously adding supply chain vulnerabilities to our stack when I don't have real pain to do so.
> Sure it is, and that's why I'm looking forward to systemd's Run0 -- but for now, there's just no way around the sudo package.
> I'm not fond of consciously adding supply chain vulnerabilities to our stack when I don't have real pain to do so.
I split my usage. Homebrew for OS things mise for the various tooling.
The only problem some things still have a dependency on requiring python and others on the system. The problem being that they’re there, mise works just fine.
You can use mise for install homebrew items btw so if you get a new computer you just drop the config.toml inside the mise and install.
This is all you have to add to the config file:
[bootstrap.packages]
"brew:git" = "latest"
"brew-cask:ghostty" = "latest"
Homebrew does this as well, I keep my packages synced with a Brewfile in chezmoi. Obv this only works for brewed packages though.
I've found `mise` more useful solely because it also handles things like tasks and daemons.
I also started using Mise for global CLI tools instead of brew and it’s working really well
Eg: mise use -g gcloud instead of brew install xxx
It can even do that for npm packages! Like mise use -g npm:xxx
re: npm, if you upgrade your global node version, you will lose that installation, right?
no, in fact you don’t even need node or npm to install npm packages with mise. (You likely will need it to execute them though)
The GUI is pretty sharp, but I don’t like it uses emoji instead of SF symbols.
Is it Claude or Codex built?
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.
Have we pinned down the emdashes source yet? ;-P
I think it's because LLMs tend to obsessively write in a this-therefore-that kind of way, where an emdash is often the most semantically fitting punctuation.
Apple devices produce a ton of emdashes; "Smart Punctuation" is enabled by default on iOS and iPadOS, maybe Mac as well - and it's at least a decade old.
I've had to disable it on all my iDevices bc it breaks some Markdown parsers. How big a % of training data was produced on an Apple device? Ehhhhh probably small.
I don’t get these questions asking if it’s codex or Claude – I see them often. Does it matter? There are other options out there also, it feels strange to ask this. Like asking “is your car a Toyota or a BMW?“
If you say "AI tools", some vibe-coders try to equivocate between tools that generate the whole program for you and, like, an editor that uses an scoring algorithm to decide which method to show at the top of an autocomplete list. But if you say "vibe coding", some vibe-coders try to claim that what they're doing technically isn't vibe coding because they applied some non-zero amount of testing or review during the process.
If you ask "did you build this using Codex or Claude", it removes most of the wiggle room. And it's worded pretty neutrally, so it will often get vibe-coders who aren't technically using either of those tools to say something like, "Actually, I've built a custom harness for DeepSeek..." instead of an outright denial.
Long term it matters very much if your car is Toyota or BMW or Kia or John Deere though.
I think some users are also conscious about the longevity of their tooling related to LLM usage, too. Whether it has an effect or not, we've yet to find out.
Farewell, Homebrew. It's been a good run.
- 2019 Intel iMac user.
Sorry we couldn’t support this for longer :(
From the release notes:
> The Intel support decision reflects the limits of a volunteer-run project: Apple have dropped Intel x86_64 support from macOS 27 Golden Gate and GitHub Actions will retire Intel macOS runners in autumn 2027. If Apple and Microsoft’s GitHub, two of the world’s largest technology companies, cannot continue supporting macOS Intel x86_64, sadly neither can Homebrew. MacPorts still supports macOS Intel x86_64 and is likely to provide better results on this platform.
My personal opinion, but I'd rather see wider macOS support than Linux support, if it's a sheer matter of where time is allocated.
Linux already has world class package managers.
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).
Homebrew is incredibly useful for immutable Linux distributions.
That said, after trying Bazzite I now prefer CachyOS and Arch as a whole.
I can see the appeal of using Homebrew and Flatpak to keep OS updates a little more separate from app updates, although I don't really see a specific need for it for myself.
How come that MacPorts supports macOS versions all the way back to 10.5 Leopard in the latest version?
Breadth of support and retention of historical support are also priorities that differ between other software distributions, especially free operating systems.
See Debian vs. Ubuntu, or NetBSD vs. DragonflyBSD.
Some software distributions emphasize package freshness and coverage, like Homebrew does, which multiplies the support burden involved for each architecture or platform supported.
Others have a more prominent focus on backwards compatibility or exotic architectures, but have a smaller or slower-moving package set.
That's an excellent question for the maintainers of the MacPorts project! It can supplement the very clear and polite answer you've already received from a maintainer of Homebrew.
The polite Homebrew project that used to market themselves with "MacPorts driving you to drink?" on their website.
They've never actively disallowed it, and volunteers have been happy to maintain it.
So much of GNU et al is already in Homebrew that I wonder how close you are to being able to support Intel Macs using the Linux/amd64 branch (or backend or whatever you call it) of Homebrew or something close to it, possibly after installing a few base libraries and utilities from MacPorts.
ETA: I've got Homebrew 7 building packages from source on an Intel Mac running Monterey; nothing yet required from MacPorts and a pretty minimal patch to the installer. I'd probably want to add legacy-support from MacPorts and update the macOS build environment to add it as an extra library on Intel Macs if I were to continue.
That being said, I'm sure y'all talked about continuing to support Intel Macs as source-based and ultimately decided against it, so it's unlikely that this will be interesting to the team. But let me know if I'm wrong and I'll open a couple PRs for further discussion.
> GitHub Actions will retire Intel macOS runners in autumn 2027
But why drop before that?
Thank you for all of your hard work, I’ve been very happily using Homebrew on OS X / macOS since 2010.
No need to be sorry, the situation is understandable.
very disappointed about this
I think they would be able to support older architectures under a paid contract if absolutely needed, for the right price.
Other than that, I'm grateful for the free software.
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.
You're right, expecting other people to do your work for your for free is indeed a problem with the industry!
> 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.
>We are all slowly dying one day at a time, is that how you want to spend your time?
Mindless consumption isn't going to extend your life.
Tinkering and building for fun brings joy, joy is the point of life. Tinker mindfully. “Tinker and build what matters, to you.”
In general I agree, but recycling old power hungry gear may be better for the environment in the long term.
So discard a working and perfectly good Macbook to be replaced by a new one manufactured by the World’s #1 CO2 emitter and transported probably halfway around the world in a container ship burning dirty bunker fuel.
Per unit costs are pretty low, and old Intel gear particularly energy guzzling.
That hardly happens on desktop/laptop Linux. Seems like a proprietary OS problem tbh.
You're definitely right about that. I'll admit it. If you're not the kind of person who likes to throw all your electronics out every few years to spend $thousands on new ones then the Apple ecosystem is not for you.
It's a weird situation in that the standards for mobile devices like cell phones and tablets are on the floor compared to those for PCs, so Apple's same 6-year cutoff feels respectable for smartphones but miserly for laptops.
Any modern Linux distro works great on Intel Macs. Been daily driving with Debian 13 initially and now NixOS on my MBP2015, have not used the MacOS Sequoia partition for months!
Same boat: 2018 Intel Mac mini, stuck on macOS 10.15.
When I eventually upgrade my hardware, I’ll happily use Homebrew again. In the meantime, MacPorts!
> Farewell, Homebrew. It's been a good run. - 2019 Intel iMac user.
welcome. - 2015 intel macbook user
I'm probably the millionth person to parrot this to you but my goodness you are a hero if you can tolerate the Intel Mac experience in 2026.
I thought my Intel Mac from that era was incredibly weird. Little firmware-ish things were so glitchy and sluggish. At some point the wake from sleep/lid open just took forever in ways that didn't happen on older Intel Mac models (or maybe I was going crazy). I just had this strange feeling that Apple was knowingly half-hearting their Intel drivers and products as a whole as they were putting more energy into developing Apple Silicon.
Dude, you owe it to yourself to just grab a used M2 MacBook Air or something along those lines. Treat yourself. You'll be kicking yourself for not doing so sooner. (Don't get a MacBook Neo, too many compromises including poor battery life, a used Air is much better, and if you use more than one external monitor use caution on what model/CPU you choose).
Sure, a laptop should last longer than 7 years, but this is one of those "Apple yeets out a new architecture" exceptions like the PowerPC to Intel transition. Better to accept it and move on. 7 years is still a solid run. You've only got ~2 more years left until you start losing security updates anyway.
The other machine I highly recommend is Linux/Framework 13 Pro with the Intel Core Ultra Series 3, although that's a whole different price class, and obviously not everyone can make that move in terms of software compatibility.
> used M2 MacBook Air
And what if you are a developer and need to replace a well specced Mac and don’t have serious budget, especially considering recent memory and storage price increases?
Rather than a coffee table status symbol or a fashion accessory for pretending to write a novel in the coffee shop?
If the old Intel Mac still works, what should one do? Dump it into a landfill?
I sell all my previous devices on second hand markets like eBay. That question becomes "not my problem:" whoever else is buying it has some kind of use case even though I am done with the system and it no longer fits my use case anymore.
I think that, for the parent commenter to my original comment, this Intel Mac no longer fits their use case. They can fight it and suffer or get the right tool for the job. I'm sure the person who buys it from them won't care that the current version of Homebrew doesn't work on it.
Intel Macs run Linux very well, I might add.
It should also be noted that, yes, most electronics eventually get scrapped for parts and raw materials. It doesn't really take all that long for important components to fail to a point where a computer is not really worth dealing with anymore. Yes, they can be repaired in many cases, but that's only generally worth it to a small group of vintage enthusiasts (and I say this as someone who very much enjoys vintage computing myself).
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"Adding the `-y`-s is probably cowboy shit. I do have a `brew autoremove` at the end though
I've been using homebrew for so long, I can't tell you how much it has helped me to spend more hours developing and less managing packages and updates, etc. Thank you so much, congratulations on the update!
And that's the end of Homebrew for me as a user. I like the app, but my old Intel MacBook apparently can't handle it anymore.
I'm back to the old installation methods !
I recommend MacPorts, the migration is easy, you copy the package names you installed with brew, uninstall homebrew (there's an unisntall script on brew.sh FAQ section, it will also uninstall all homebrew packages (but not the casks)) then install macports and reinstall the packages with sudo port. Although the selection is smaller on macports and newer packages might not have a prebuilt pkg for your OS so you still might end up building manually (My poor i5 4core had to attempt building nodejs26 because there wasn't a pkg for Ventura)
Actually, Homebrew 7 is supported on your Mac, you just have to install Linux to use it. :)
If you want to continue using the same MacBook that will be only path forward when Apple decides to EOL it (if it hasn't already happened).
I'm a long time Homebrew on Linux user, it works really well. I always prefer it over the distro supplied package manager for user facing CLI apps.
Apple was selling Intel Mac Pros in 2023, it's absurd these things are coming up on EOL already.
Check out MacPorts. It was the original package manager, still going strong, and it supports Macs going all the way back to the Leopard era. It also always used /opt instead of taking over /usr/bin like Homebrew.
I always found it much slower when compared to brew and sometimes would just hang and get stuck when installing something. Plus the lack of casks does make it less of a direct replacement.
I've used MacPorts on macOS versions that don't support the latest OS, which per homebrew policy seems to be versions upto N-2.
Apart from the issue of having to compile the downloaded software leading to spinning fans, I'm not too concerned.
How long do you expect them to support Intel processors though? It’s been like 6 years since the last MacBook release had any Intel processor, and Apple doesn’t make OS updates anymore, so it doesn’t surprise me that Homebrew stopped too.
Are you implying that a 6 year old hardware is as good as a paperweight? Outside of the Apple fairyland this is just bonkers.
I'm not blaming the Homebrew project/developers here, but the fact that many people are okay with deprecating perfectly fine hardware.
No, he’s asking what you think a reasonable support timeline is. An open source project supporting hardware 6 years old is pretty awesome.
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.
Bits certainly don’t rot and you’re welcome to stay on the latest stable version that runs on your architecture.
And if you want new bits with the new features, those aren’t the same bits and that work isn’t free.
Exactly. That's all I'm asking for. If version X works on my system today and version Y needs an OS bump, well... that sucks and is avoidable, but whatever. I expect to be able to obtain and use version X tomorrow and into the future. That's it. I'm not asking to make version Y work for me, but it would be nice if they didn't add the OS dependency.
But increasingly, developers can't even manage to keep version X around and working, despite them having to simply not do anything to it to keep it from breaking.
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.
Software maintenance is not free, especially for a project the size of Homebrew, and it's perfectly reasonable for software to not be supported on older computers due to maintenance burden, with a good example being 32 bit processors. If you had a 32 bit processor would you expect all of your software that was supported now to be supported forever, just because it supports it now?