[HN Gopher] Nanobrew: The fastest macOS package manager compatib...
___________________________________________________________________
Nanobrew: The fastest macOS package manager compatible with brew
Author : syrusakbary
Score : 155 points
Date : 2026-03-24 11:40 UTC (11 hours ago)
(HTM) web link (nanobrew.trilok.ai)
(TXT) w3m dump (nanobrew.trilok.ai)
| an0malous wrote:
| Does it reinstall postgres for every package install?
| mitchitized wrote:
| (report card for an0malous): "Does not play nice with other
| students."
| an0malous wrote:
| It's true :')
| ericcholis wrote:
| HOMEBREW_NO_AUTO_UPDATE=1 will disable this (annoying)
| behavior. Set it in your bashrc or zshrc.
| chuckadams wrote:
| This might be a good thing for homebrew to adopt for the
| download/install process, but if it doesn't include a ruby
| interpreter, I have a hard time seeing how it's going to be
| compatible with anything but searching and installing bottles. I
| install most of my packages from a Brewfile, which itself is Ruby
| code.
| alwillis wrote:
| > I install most of my packages from a Brewfile, which itself
| is Ruby code.
|
| Same. Whatever happens, the new version should support
| Brewfile.
| mikemcquaid wrote:
| 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 have full compatibility. Hopefully this will help share
| effort across the wider ecosystem.
| pxc wrote:
| It is really coll that Homebrew provides a comprehensive enough
| JSON API to let people build on Homebrew in useful ways without
| directly running Ruby, despite everything being built in a Ruby
| DSL. That really does seem like a "best of both worlds" deal,
| and it's cool that alternative clients can take advantage of
| that.
|
| I didn't know about the pending, official Rust frontend! That's
| very interesting.
| SOLAR_FIELDS wrote:
| Wow they are finally getting away from Ruby? Awesome. The
| speed will be a nice boon
| petcat wrote:
| Yeah I don't know why people are saying that speed doesn't
| matter. I use Homebrew and it is slow.
|
| It's like yum vs apt in the Linux world. APT (C++) is fast
| and yum (Python) was slow. Both work fine, but yum would
| just add a few seconds, or a minute, of little frustrations
| multiple times a day. It adds up. They finally fixed it
| with dnf (C++) and now yum is deprecated.
|
| Glad to hear a Rust rewrite is coming to Homebrew soon.
| novok wrote:
| Ruby doesn't have to be the slow part, bazel uses
| starlark which is mostly python and it's very fast.
| kelvie wrote:
| One of the reasons I switched to arch from debian based
| distros was precisely how much faster pacman was compared
| to APT -- system updates shouldn't take over half an hour
| when I have a (multi)gigabit connection and an SSD.
|
| It was mostly precipitated by when containers came in and
| I was honestly shocked at how fast apk installs packages
| on alpine compared to my Ubuntu boxes (using apt)
| akdev1l wrote:
| pacman is faster simply because it does less things and
| it supports less use cases.
|
| For example pacman does not need to validate the system
| for partial upgrades because those are unsupported on
| Arch and if the system is borked then it's yours to fix.
| akdev1l wrote:
| yum was slow not because of python but because of the
| algorithm used to solve dependencies
|
| Anyway the python program would call into libsolv which
| is implemented in C.
|
| dnf5 is much faster but the authors of the program credit
| the algorithmic changes and not because it is written in
| C++
|
| dnf < 5 was still performing similarly to yum (and it was
| also implemented in python)
| wavemode wrote:
| > dnf < 5 was still performing similarly to yum (and it
| was also implemented in python)
|
| I'm perhaps not properly understanding your comment. If
| the algorithmic changes were responsible for the improved
| speed, why did the Python version of dnf perform
| similarly to yum?
| akdev1l wrote:
| Because dnf4 used the same dependency resolution as yum
| but they revamped it in dnf5 (it was initially supposed
| to be a whole new package manager with a different name)
| mhurron wrote:
| > Yeah I don't know why people are saying that speed
| doesn't matter. I use Homebrew and it is slow
|
| Because how often are you running it where it's not
| anything but a opportunity to take a little breather in a
| day? And I do mean little, the speedups being touted here
| are seconds.
|
| I have the same response to the obsession with boot
| times, how often are you booting your machine where it is
| actually impacting anything? How often are you installing
| packages?
|
| Do you have the same time revulsion for going to the
| bathroom? Or getting a glass of water? or basically
| everything in life that isn't instantaneous?
| pxc wrote:
| I would guess this change builds on the existing json
| endpoints for package metadata but that the Ruby DSL is
| remaining intact.
|
| I think how to marry the Ruby formulas and a Rust frontend
| is something the Homebrew devs can figure out and I'm
| interested to see where it goes, but I don't really care
| whether Ruby "goes away" from Homebrew in the end or not.
| It's a lovely language, so if they can keep it for their
| DSL but improve client performance I think that's great.
| atonse wrote:
| 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!)
| samgranieri wrote:
| I think Max Howell created Homebrew. I think McQuaid is the
| current maintainer
| tfrancisl wrote:
| I appreciate the push for an official rust frontend. I've
| personally been migrating (slowly) to using nix to manage my
| Mac's software, but there are a ton of limitations which lead
| me to rely on homebrew anyway. The speed ups will be
| appreciated.
| boobsbr wrote:
| Please, don't remove bottles and casks that are blocked by
| Gatekeeper. :~(
| halapro wrote:
| Makes no sense, the wording suggests it can use Homebrew's
| backend, not that it's a complete alternative to Homebrew.
| Nobody is confused about that.
| nozzlegear wrote:
| I mean, I'm confused about it. The nanobrew homepage says
| this:
|
| > _nanobrew_
|
| > _The fastest macOS package manager. Written in Zig._
|
| > _3.5ms warm install time_
|
| > _7,000x faster than Homebrew * faster than echo_
|
| It presents itself as an alternative to Homebrew.
| halapro wrote:
| There are many such examples for npm as well: many
| "compatible" managers, one registry.
| nozzlegear wrote:
| Sorry, examples of what? Package managers that present
| themselves as replacements for other package managers? Or
| package managers that aren't compatible with the registry
| they're supposed to be compatible with? Your use of scare
| quotes is confusing.
| 0x457 wrote:
| pnmp, npm, yard all have different lockfiles, all use the
| same registry format (and the same registry itself), all
| try to stay compatible in other ways.
|
| You won't be having situation where one uses yarn and
| someone uses pnpm on the same project tho.
| akdev1l wrote:
| The recipes for building and installing homebrew packages are
| written in Ruby
|
| You cannot really be compatible with this unless you run the
| Ruby as the install scripts could do whatever arbitrary
| computations
|
| In reality most recipes contain a simple declarative config
| but nothing stops you from doing Ruby in there.
|
| Hence to achieve total compatibility one would need to run
| Ruby
| saghm wrote:
| Is this still true since they swapped to distributing
| binaries rather than building from source on each install?
| It's been years since I last installed something from
| homebrew that built from source, so something that could
| install the same binaries would be compatible from my
| standpoint.
|
| That said, it's also been a while since I've really had any
| huge complaints about brew's speed. I use Linux on my
| personal machines, and the difference in experience with my
| preferred Linux distro's package manager and brew used to
| be laughable. To their credit, nowadays, brew largely feels
| "good enough", so I honestly wouldn't even argue for
| porting from Ruby based on performance needs at this point.
| I suspect part of the motivation might be around concerns
| about relying on the runtime to be available. Brew's use of
| Ruby comes from a time when it was more typical for people
| to rely on the versions of Python and Ruby that were
| shipped with MacOS, but nowadays a lot of people are
| probably more likely to use tooling from brew itself to
| manage those, and making everything native avoids the need
| to bootstrap from an existing runtime.
| akdev1l wrote:
| It can revert back to building from source under some
| cases and I still think even when doing binary downloads
| it will execute install hooks which are ruby inside the
| recipe
|
| I would agree with you that probably Ruby itself is
| probably not the bottleneck (except maybe for depsolving
| cuz that's cpu bound)
| orf wrote:
| https://github.com/Homebrew/brew/tree/main/Library/Homebrew/...
| for reference
| runjake wrote:
| Context for those unaware: the commenter, mikemcquaid, is the
| project lead for Homebrew.
| Xunjin wrote:
| 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.
| runjake wrote:
| Point noted! I took it as a tongue-in-cheek phrasing of
| "agentically coded". Hopefully, that's right.
| alwillis wrote:
| Since I enabled HOMEBREW_DOWNLOAD_CONCURRENCY, downloads
| have improved for me to the point where download speed is
| no longer an issue.
| brailsafe wrote:
| Good to know! I was doing this with a hacky one-liner but
| wasn't aware of this flag. I think the sequential
| build/install process is the agonizing bit though.
| jazzpush2 wrote:
| Yeah, tbh homebrew is slow as fuck. It literally took 30
| minutes to install aws cli on my 2020 mbp. I will happily
| flock to every new version that's faster.
| mpalmer wrote:
| I don't see where he said it's a bad thing, or even implied
| it. As I see it, he did imply that superlatives like THE
| FASTEST PACKAGE MANAGER aren't worth much in this
| environment.
| rbanffy wrote:
| > Alternatives often are not a bad thing.
|
| Exactly. I've been using MacPorts for ages and I love it.
|
| /me ducks.
| derefr wrote:
| > Homebrew is working on an official Rust frontend that will
| actually have full compatibility.
|
| When you say "Rust frontend", is the vision that Homebrew's
| frontend would eventually transition to being a _pure_ Rust
| project -- no end-user install of portable-ruby and so forth?
|
| If so (ignore everything below if not):
|
| I can see how that would work for most "boring" formulae:
| formula JSON gets pre-baked at formula publish time; Rust
| frontend pulls it; discovers formula is installable via bottle;
| pulls bottle; never needs to execute any Ruby.
|
| But what happens in the edge-cases there -- formulae with no
| bottles, Ruby `post_install` blocks, and so forth? (And also,
| how is local formula development done?)
|
| Is the ultimate aim of this effort, to build and embed a tiny
| little "Formula Ruby DSL" interpreter into the Rust frontend,
| that supports _just_ enough of Ruby 's syntax + semantics to
| execute the code that appears in practice in the bodies of real
| formulae methods/blocks? (I personally think that would be
| pretty tractable, but I imagine you might disagree.)
| drob518 wrote:
| 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.
| pxc wrote:
| If you use the Homebrew module for Nix-Darwin, running `brew`
| against the generated brewfile becomes the slowest part of a
| `darwin-rebuild switch` by far. In the fast cases, it turns
| something that could take 1 second into something that takes
| 10, which is definitely annoying when running that command is
| part of your process for configuration changes even when you
| don't update anything. Homebrew no-ops against an unchanging
| Brewfile are really slow.
| dilap wrote:
| Horses for courses, but I've stopped using brew 'cuz it's too
| slow, so this might bring me back!
|
| Edit: no, it won't...
| drob518 wrote:
| Agreed on horses for courses. Different people have different
| tolerances. And yea, all things being equal, faster is
| better, but they are almost never equal. If you don't mind me
| asking, what does "too slow" mean for you in this context? Do
| you have a particularly complex setup? And what do you use
| now as an alternative and how has that impacted the update
| speed?
| dilap wrote:
| I wish I could remember the details -- I know I got annoyed
| with things being slow and when I got a new computer
| decided to go the no-homebrew route. I'm using nix, and it
| seems fine so far, but I also really don't understand it at
| all, which is a little concerning. :-)
| swiftcoder wrote:
| > I've never sat there thinking "If this was only 2 seconds
| faster..." while doing an update
|
| I definitely have thought something along those lines (mostly
| when I go to install a small tool, and get hit with 20 minutes
| of auto-updates first).
|
| Pretty sure I also will not be adopting this particular
| solution, however
| bombcar wrote:
| I've never thought "only 2 seconds faster" - I've certainly
| thought "why is this taking half the time it takes Gentoo to
| recompile an entire server".
| SOLAR_FIELDS wrote:
| FWIW this seems to have improved in recent years. Back in the
| dark times of non parallelized downloads I would purposefully
| wait to end of day and fire the thing off before leaving
| joshstrange wrote:
| 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).
| slackfan wrote:
| Terrible default behavior is a great reason to abandon a
| software package.
| swiftcoder wrote:
| I'd be much happier if it were on a background job, than
| arbitrarily running when I invoke a command
| saghm wrote:
| I'm not sure if I just have way fewer things installed than
| most people or I just update more often, but I haven't
| experienced anything like this for years. I run `brew
| upgrade` probably around once every (work)day, usually right
| before doing a git pull or something, and then I'll quickly
| look at a couple emails or slack messages, and then it's
| always done by the time I switch back
| mproud wrote:
| My brew update/upgrade takes forever
| noahbp wrote:
| The same criticism has been said of Deno and Pnpm and bun, and
| yet, despite all these years since their respective releases,
| node and npm remain slower than all three options.
| never_inline wrote:
| Well, pnpm solves the storage issue, which is a more pressing
| reason to use it. (I don't know about deno/bun)
| fleebee wrote:
| Yeah, but do they _work_? Last time I gave bun a chance their
| runtime had serious issues with frequent crashes. Faster
| package installation or spin-up time is meaningless if it
| comes at the cost of stability and compatibility.
| alwillis wrote:
| bun is my go to for npm packages; it's so much better and
| faster than npm, it's not funny.
|
| Never had any issues.
| ziml77 wrote:
| Agreed here. The speed bottleneck I run into is simply that
| there's often a lot of packages that need updating, so there's
| a lot to download. And if anything needs to be compiled from
| source then the time that takes will dominate (though I think
| everything I currently run is thankfully pre-built)
| motorpixel wrote:
| If I have to deal with even the mention of another package
| manager in the cross-platform dev ecosystem I am going to snap
| staticassertion wrote:
| I've wanted brew to be faster. It would be a nice QoL for me.
| password4321 wrote:
| See also: asdf and mise
|
| https://github.com/asdf-vm/asdf/issues/290#issuecomment-2365...
| rconti wrote:
| I've been a lightweight homebrew user for many, many, many
| years now. I just use it to download or update a thing I need,
| once every 3-6mo.
|
| It constantly blows my mind how insanely long it takes just to
| do a few simple things on the fastest hardware I've ever owned
| in my life.
| saghm wrote:
| Brew definitely used to be a lot slower, and I used to find it
| very tedious. I feel like they've done a reasonably good job in
| improving that over the years though (with the switch to
| distributing binaries by default being a huge win in terms of
| speed). I have to wonder if stuff like this is more due to
| lingering feelings from before combined with the easy access to
| vibe coding tools. If LLM coding came a few years earlier,
| maybe projects like this one would have made more sense to me.
| pxc wrote:
| I've been looking for something like this, especially to use only
| with casks now that Homebrew has removed support for not adding
| the quarantine bit. Looking forward to giving it a try!
| kassadin wrote:
| Do you choose compatibility or speed?
|
| nb info --cask codex-app
|
| nb: formula '--cask' not found
|
| nb: formula 'codex-app' not found
| luizfelberti wrote:
| It might be good to explain how this differs from zerobrew [0],
| which is trying to accomplish the same thing
|
| [0] https://github.com/lucasgelfond/zerobrew
| tomComb wrote:
| And zerobrew, like the original Homebrew, is compatible with
| Linux.
|
| It appears that Nanobrew is not.
|
| I care about the light-weight efficiency of these new native
| code variants much more when I want to use brew on some little
| Linux container or VM or CI, than I do for my macOS development
| machine.
| Alifatisk wrote:
| Zerobrew looks mature, I'll check it out.
|
| Btw, I noted this:
|
| > Zerobrew is experimental. We recommend running it alongside
| Homebrew rather than as a replacement, and do not recommend
| purging homebrew and replacing it with zerobrew unless you are
| absolutely sure about the implications of doing so.
|
| So I guess its fine to run this alongside Homebrew and they
| don't conflict.
| phist_mcgee wrote:
| >Install zerobrew via brew as per the official instructions.
|
| >Immediately get an error saying the install path is too long
| and needs to be fixed as /opt/zerobrew/prefix is too many
| bytes.
|
| Yeah gonna need some work.
| alsetmusic wrote:
| I'm not a Python dev, but I appreciate the motivation uv has
| inspired across other package managers. I tried another brew
| replacement called zerobrew last month. It installed packages to
| a different directory from homebrew, so I didn't actually test
| drive after seeing that. Regardless, I look forward to the
| competition pushing mainstream tools to improve their
| performance.
| ryandrake wrote:
| What would be great is a Homebrew-compatible system that doesn't
| cut off support for older machines. I have a 3.8 GHz Quad core i5
| iMac that still crushes, yet Homebrew has determined that I'm
| just too old and icky[1] to work with anymore. I had to move over
| to MacPorts, which is surprisingly nice, but I still miss brew.
|
| Yea, I know. It's open source. They can do what they want. Still
| sucks.
|
| 1: https://docs.brew.sh/Support-Tiers
| happyopossum wrote:
| 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_
| gabagool wrote:
| I agree in principle but Homebrew only supports the latest 3
| versions of macOS. Right now Ventura 13 which came out in
| October 2022 is unsupported.
| dewey wrote:
| I still think that's entirely fair for a power user tool
| like homebrew. With the upgrade rates of macOS that
| probably means that's 98% of the users would be covered.
| Expecting an open source project to accept bug requests
| from a bigger variety of versions that then would need test
| devices on these versions to replicate issues sounds
| unrealistic. Bigger companies, or Apple itself I would hold
| to much higher standards when it comes to that.
| ksherlock wrote:
| brew used to say, more or less, "This OS is old and
| unsupported. Don't submit bug reports. If you have
| problems, too bad. If you submit a PR to fix something,
| we might merge it". Fair enough, right? Now it just says,
| "Go fuck yourself, grandpa."
| bsagdiyev wrote:
| > power user tool like homebrew.
|
| That makes no sense then. A power user may still want to
| run older OS versions for a reason. Take the training
| wheels off it and then it'll be a power user tool.
| dewey wrote:
| > A power user may still want to run older OS versions
| for a reason.
|
| No doubt there are edge cases like that, but I don't
| fault a project for not catering to the < 1% of users who
| would fall into that bucket and would probably be the
| ones that cause trickier support cases. These would maybe
| also be the user that could just install it without
| homebrew then, it's not like homebrew is the only way to
| install software.
| edschofield wrote:
| This is not an edge case. Most HN commenters describe the
| latest two versions of macOS as being objectively worse
| than earlier versions: slower, less stable, more broken.
| There are significant numbers of "power users" who
| deliberately avoid upgrading or have actively downgraded
| macOS to Sonoma because they care about their computing
| experience.
| dewey wrote:
| People who downgraded to Sonoma are the definition of an
| edge case, maybe you hear from some of them on HN and it
| sounds like a big group but this is a niche of a niche.
|
| https://telemetrydeck.com/survey/apple/macOS/versions/
| rbanffy wrote:
| 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.
| password4321 wrote:
| Yes MacPorts is the way. I switched after a new MacOS release
| meant mine was too old - brew update uninstalled a bunch of
| stuff I had been using then it stopped and let me know.
|
| There's also https://github.com/dortania/OpenCore-Legacy-
| Patcher for the adventurous.
| maxkfranz wrote:
| You could use the OpenCode legacy patcher to upgrade to
| v15/Sequoia: https://dortania.github.io/OpenCore-Legacy-
| Patcher/
| ryandrake wrote:
| Sure, but this might win you a couple of years max.
| Homebrew's "Support Tiers" page, which I linked, also
| addresses OCLP users, going so far as to specify a minimum
| Intel architecture. So, even if you use OCLP to allow support
| for newer OS versions, eventually your CPU architecture will
| be too old and you're back in Tier 3.
|
| Also, the writing is on the wall: Ultimately, Homebrew will
| be ARM-only, once Apple's legacy support becomes ARM-only. At
| which point it's game-over for Intel Macs.
|
| Homebrew solves the "availability of software" problem in the
| Mac ecosystem, but it does not solve the "Need to stay on the
| new hardware treadmill" problem.
| yabutlivnWoods wrote:
| Run Linux on it. Apple has cut that OS off anyway. Would be
| safer security wise to have an OS that's updated
| tantalor wrote:
| And why does speed matter in this case?
| manlymuppet wrote:
| If we get the Bun-ification of every package manager and language
| ecosystem that would be an awesome thing. This is a great trend.
| maxloh wrote:
| How does this work? AFAIK Homebrew formulae are written in Ruby
| [0].
|
| Do they use some kind of Ruby parser to parse formulae?
|
| [0]: https://github.com/Homebrew/homebrew-
| core/blob/26-tahoe/Form...
| fny wrote:
| It uses the Homebrew API and uses its own dependency resolver
| and linker to pull Homebrew's precompiled packages.
| Onavo wrote:
| The current version of brew has a flaw where the installer can't
| install isolated dependency trees in a sterile manner. If you
| have packages A, B, C, and D that all have updates, and assuming
| A,B,C depend on each other and come out to a total of say 1MB,
| and D is 1000MB, brew works in a MapReduce manner where it will
| attempt to finish downloading everything in parallel (even though
| the real bottleneck is D) before doing any installation.
|
| Since the first 3 has no dependency on D, a better way would be
| to install them in parallel while D is still downloading.
| marksully wrote:
| what happens if I test this tool by installing some packages and
| then remove (the tool)? will I still be able to use Homebrew to
| manage these new packages?
| 12_throw_away wrote:
| So, A) to what extent is this vibe coded? And B) what is
| "trilok.ai" where you download it from?
| themadsens wrote:
| I naively assumed it would work on the _already_ installed
| homebrew packages. No such luck.
|
| After installing, 'nb list' and thus eg. 'nb outdated' will yield
| the empty list! I have absolutely no use for a competing homebrew
| installation that is _mostly_ compatible ..
| hsaliak wrote:
| This is most certainly vibed with a few optimization focused
| prompts. Yes - performance is a feature, but so is lack of risk.
| MoonWalk wrote:
| Inaccessible: net::ERR_CERT_AUTHORITY_INVALID
| tzs wrote:
| OT: speaking of Homebrew, I made an incorrect assumption about it
| that eventually led to some problems. It was me being stupid, but
| I bet others have made the same mistake but not yet hit problems.
| Hence this comment.
|
| My mistake was when I upgraded from my 2017 iMac (Intel
| processor) to an Apple silicon Mac at the start of 2024 and
| migrated via Time Machine I did not do anything extra
| specifically for Homebrew. I just assumed that as things got
| updated via the normal periodic Homebrew updates I run it would
| start grabbing the Apple silicon binaries for binary things it
| installed.
|
| It turn out that is wrong. They made Apple silicon Homebrew kind
| of independent of Intel Homebrew. Intel Homebrew uses /usr/local
| and Apple silicon Homebrew uses /opt/homebrew. This allows having
| both native and Intel Homebrew installed at the same time if you
| need both.
|
| The correct way to migrate from an Intel Mac to an Apple silicon
| Mac is to install Apple silicon Homebrew on the new Mac, and then
| install all the packages you want. Intel Homebrew works fine on
| Apple silicon Macs so you can use the Intel Homebrew that
| migrated via Time Machine to make the package list to use with
| Apple silicon Homebrew (or you can make it on the old Mac).
|
| I only noticed this because I was trying to build something from
| source using some libraries that were installed via Homebrew and
| running into problems. An LLM was helping figure this out and it
| was telling me I might have to manually symlink those libraries
| from where they were in /opt/homebrew to where the build process
| for the thing I was building expected to find them and I didn't
| have a /opt/homebrew. The libraries were somewhere in /usr/local.
| I then noticed those libraries were not for Apple silicon,
| checked other things installed view Homebrew and saw nothing was
| for Apple silicon, and realized I had the wrong Homebrew.
___________________________________________________________________
(page generated 2026-03-24 23:00 UTC)