_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Show HN: Homebrew 6.0.0
NamlchakKhandro wrote 23 hours 42 min ago:
Can you pin PKG in brew yet?
Honestly just use mise instead.
ronef wrote 1 day ago:
A small note of amazement from Nix/Flox person here. Incredible to see
this release and congrats! Mike, you're an allstar for so many years of
contributions!
divbzero wrote 1 day ago:
I totally missed the memo that Homebrew has supported Linux since 2019.
HTML [1]: https://brew.sh/2019/02/02/homebrew-2.0.0/
miki123211 wrote 1 day ago:
Is there any good reason for Homebrew to keep its .tar.gz files around,
even after packages are installed?
I'd personally love a "Homebrew light", compatible with most of the
ecosystem (sans git taps, Ruby formulas and binary packages), written
in a language with fast startup times, not keeping unnecessary files on
disk, with support for parallel downloads, and terminology that is much
easier for the newcomers to remember and keep straight.
lanycrost wrote 1 day ago:
You need to rethink about this tierings [1] many teams have old MacOS
versions for build and other purposes and they face issues when they
need to use packages for old versions. For example I use fully
automated machine creation (packer, tart, vmware, etc.) and when we
need to update let's say Monterey image it require to compile bunch of
packages which is real headache.
HTML [1]: https://docs.brew.sh/Support-Tiers
OJFord wrote 1 day ago:
Ah, I was excited by 'sandboxing on Linux', but it's only for build.
How many more supply chain attacks will it take for someone to build a
really great sandboxing/permissioning system, that's easy enough to use
that we actually use it?
Say I install an `ls` alternative (because it's on the HN front page as
'ls but in lang du jour' or whatever) â it should be really simple
for me to allow it read-only access to only the passed directory. I
don't think firejail or apparmour even supports that, and it'd probably
take me half a day to figure it out in bubblewrap.
I just want a mobile-OS style pop-up the first time programs try to do
something for me to deny, approve always, approve this time, approve by
dir, or custom thing matching on the args.
gcr wrote 1 day ago:
Sounds like a great idea, thanks for volunteering to pitch in and
help!
OJFord wrote 1 day ago:
It wasn't a criticism, I was just excited for a second thinking
"Homebrew's doing this, I trust that it's probably doing it well, I
definitely want to check this out".
TomMasz wrote 1 day ago:
Homebrew has been a gamechanger for me, thanks for all your efforts!
pojzon wrote 1 day ago:
Thank you fore homebrew. It makes macos usable.
sgt wrote 1 day ago:
Well done, a milestone. I can't say how much I appreciate Homebrew,
been using iti for years, at least 15 years.
ricksunny wrote 1 day ago:
Is uninstalling homebrew still as much of a mess as it was when I tried
to do it in 2022 (when it left behind a messy install footprint on my
Mac)?
mattcox12 wrote 1 day ago:
Internal JSON API being default is the real improvement here. brew
update has been too chatty for years, cutting that down makes a big
difference.
MikeNotThePope wrote 1 day ago:
This is somewhat impressive, but can you reverse a binary tree?!
HTML [1]: https://www.quora.com/Whats-the-logic-behind-Google-rejecting-...
bartvk wrote 1 day ago:
Yeah, I remember this story too. Crazy, it most definitely feels like
the organization missed an opportunity.
hendry wrote 1 day ago:
Iâve also dropped nix-darwin for homebrew on my new m5.
Fantastic work Mike and team, though Iâm still a little confused
about cask upgrades.
port11 wrote 1 day ago:
Ask mode being the default is stellar. Thanks Mike!
Apple couldâve made something like this, or at least pay you
handsomely for making Macs better to use.
kh2engab wrote 1 day ago:
Is there a way to run the cask/tap search via browser address-bar %s?
Like this:
HTML [1]: https://www.digikey.com/de/products?keywords=%s
nxpnsv wrote 1 day ago:
I noticed the change to trust already in the previous release. To
uninstall something from a not yet trusted tap, I first have to trust
it, then uninstall, and then untrust it. This feels a bit weird, but
maybe it makes total sense...
mikemcquaid wrote 1 day ago:
This sounds like a bug. Can you file an issue?
usernametaken29 wrote 1 day ago:
Mac without brew just wouldnât be Mac. Huge respect!
user3939382 wrote 1 day ago:
With NetBSD and Macports, when I need to find a file I can predict
where it is almost every time. With FreeBSD, Linux, and Brew, it feels
like âhere we goâ while I guess. Since tools in categories like
this are similar, things like this end up being tie breakers for me.
ProAm wrote 1 day ago:
Remember when this guy couldn't get hired at Apple, because Apple
doesn't respect their customers or developers.....
mikemcquaid wrote 1 day ago:
Iâve never applied for a job at Apple.
Youâre maybe thinking of the creator mxclâs viral tweet about not
getting hired at Google. He did work at Apple for a while on SwiftPM.
I also am in the âapplied and didnât get hired by Googleâ club
which let me move back to Scotland instead :)
hk1337 wrote 1 day ago:
Does this fix the issue why the aws session-manager-plugin has to be
removed?
Also, what about installation directories? I always install homebrew to
~/.brew since I know Iâll always have access to my home directory
without sudo.
luckykiddie wrote 1 day ago:
I have been used Homebrew for years, the first choice to install an App
is using the `brew install --cask` command.
But can you please support old Mac too? As you upgrade brew, many brew
break for old Mac since the old library/framework. And in this
situation, i had to switch from brew to macports plus brew. It's a pain
for old Mac to using brew.
mikemcquaid wrote 1 day ago:
Sorry, we donât have the resources to do so. We are a team of
volunteers and rely on donations to pay for our CI infrastructure.
MacPorts is a better fit for older hardware.
alsetmusic wrote 1 day ago:
Top three things I install first are Sublime Text, Homebrew, and modern
Bash (I'm not switching to Zshell). Great tools make computing
enjoyable.
strunz wrote 1 day ago:
Homebrew first, then use it to install Sublime and Bash!
drgo wrote 1 day ago:
As a daily user of Homebrew for > 10 years, thanks for all your hard
work.
academicfish wrote 1 day ago:
Thanks
redml wrote 1 day ago:
absolutely solid, thanks!
tiahura wrote 1 day ago:
Seems like the sort of package that waiting on 6.0.1 might make sense.
cbeach wrote 2 days ago:
Slightly tangential, but I went to set up Homebrew today on a new Mac.
Stupidly clicked the top link in Google (which was sponsored but not
obviously so). Took me to a spoof Homebrew page. I ran the script.
Typed in my Mac password like a fool when prompted, and nothing
happened. Then I realised what an idiot Iâd been.
Claude found evidence of an exfiltration malware on my laptop and I
inmediately wiped the device and started again. Revoked all my keys,
rotated all my passwords. And now I pray the damage is contained.
I canât believe that Google would have let this slip through. I
probably wasn't the only one that got caught out.
mikemcquaid wrote 1 day ago:
Weâve complained about this to Google many times to no avail.
Itâs very frustrating. They are literally paid money to let people
install malware on your machine. Please direct all annoyance and
resentment to them (we share it).
cbeach wrote 1 day ago:
Firstly, Mike, thank you for all you've done with HomeBrew - an
amazing product. None of my ire was directed at you or HomeBrew.
I am so frustrated at Google, not just for this incident, but for
many reasons (like their inexplicable shutdown of my own Adsense
account years ago, and their neglect of several products I'd built
against or bought). When they act, they leave us with no recourse.
I feel anxious being dependent on them, even for simple stuff like
my email account.
They are sufficiently big that they no longer care about the little
guy anymore. They are only interested in swallowing up all the
World's data and cashing in on Workspace.
mikemcquaid wrote 1 day ago:
Thanks for the kind words. Glad no ire directed at us. It is very
frustrating I agree.
sgt wrote 1 day ago:
I've heard of that but never experienced it on my Google. Weird. I
just retried that now and it's giving the correct link. Maybe that's
why it's not being fixed.
cbeach wrote 1 day ago:
I reported the ad to Google immediately, and when I checked back an
hour later the search results were clear. But I suspect it's only a
matter of time before another one slips through the net.
I think what happens is a legitimate business with a history of
legit Google advertising gets compromised by malware, and then
their Google adverts are flipped.
cbeach wrote 3 hours 30 min ago:
Just heard back from Google regarding my report of the ad that
served malware to me:
> Dear Chris,
> Weâre writing to let you know that we reviewed your report
(ID 579240969280369002).
> Here's what we found
> We decided not to take this ad down. We found that the ad
doesnât go against Googleâs policies, which prohibit certain
content and practices that we believe to be harmful to users and
the overall online ecosystem.
I think the safest thing I can do right now is avoid using Google
for searches and instead use Claude, which at least has
functioning safeguards, and is less easily poisoned than Google
Search.
linsomniac wrote 2 days ago:
Trying to understand if nix/nix-darwin is an alternative here. I just
switched over my work machine to NixOS and I'm totally loving it. So
far I've only used nix on Mac to install Wezterm, because I need the
Linux and Mac versions to be exactly the same and the normal Mac
downloader and Nix don't have matching versions, and that worked well.
bodzioney wrote 1 day ago:
To brew? Sort of. I use nix-darwin for everything. However, some
things donât play nice with nix. In that case you can use
nix-darwin to manage brew. Basically you give it all the packages you
want, and it generates a brew file and uses it.
phs318u wrote 2 days ago:
Back in the day, pkgsrc was a thing (cross-platform; originally from
NetBSD). Source based package distribution, it explicitly allowed for
unprivileged installation to a prefix of your choice. I became very
familiar with it as an ordinary Solaris user 20 years ago.
jperkin wrote 2 days ago:
It's still a thing:
HTML [1]: https://pkgsrc.smartos.org/install-on-macos/
delduca wrote 2 days ago:
Thanks for the homebrew and all work over those years!
commandersaki wrote 2 days ago:
Homebrew is a non-profit project run entirely by volunteers, not
employees. We need your funds to pay for software, hardware and hosting
around continuous integration and future improvements to the project.
Every donation will be spent on making Homebrew better for our users.
Please consider a regular donation through GitHub Sponsors,
OpenCollective and Patreon.
I donate to a lot of open source projects that I benefit from, but
Iâve never really thought about Homebrew. I will get onto it.
AussieWog93 wrote 2 days ago:
I'm amazed they're not sponsored by Apple themselves, or at the very
least major mac-forward Dev houses.
cromka wrote 1 day ago:
If it wasn't for Brew, macOS would have no chance against Linux as
a dev platform.
frumplestlatz wrote 1 day ago:
Apple developed â and for many years afterwards, hosted â-
MacPorts.
cromka wrote 1 day ago:
Apple employees did. Not Apple themselves. As for hosting, it
was hosted on an equivalent of SourceForge, where many other
opensource projects unaffiliated with Apple were.
And we all know how MacPorts failed to actually gain any
significant momentum.
frumplestlatz wrote 1 day ago:
No, Apple employees originally authored the project on
Appleâs time.
And it was first hosted at OpenDarwin â which was Apple-run
and not available for arbitrary public hosting.
It was then hosted at OpenDarwinâs successor â Mac OS
Forge. That was also Apple-run and not available for
arbitrary project hosting.
MacPorts was an Apple-authored and ultimately Apple-supported
project for ~15 years.
As for momentum, the project is still going strong 25 years
later, so Iâm not really sure what youâre referring to.
cromka wrote 1 day ago:
> As for momentum, the project is still going strong 25
years later, so Iâm not really sure what youâre
referring to.
I am referring to a significant momentum. You know, like
the momentum Brew has.
ryanisnan wrote 1 day ago:
I think you're right - it's one of the reasons I prefer a mac as
a dev platform.
dzonga wrote 2 days ago:
mike, thanks for ur hard work. n all the maintainers b4.
mvdtnz wrote 2 days ago:
I don't think any software has ever wasted as much of my time as Brew.
I can't think of a single positive experience I have had with it. I now
absolutely refuse to use it for any reason.
jedahan wrote 2 days ago:
I wish tap trust operated at the author/committer level than identifier
level.
m463 wrote 2 days ago:
macOS 27 (Golden Gate) drops Intel support, so
...
in September 2027, macOS Intel x86_64 will be unsupported entirely and
all related code deleted.
hmm... that's too bad.
theragra wrote 2 days ago:
I was so impressed with Homebrew, I've added a formula for far2l-tty.
Thanks for your job!
gigatexal wrote 2 days ago:
Homebrew is the first thing I install on a new Mac. I love it. Thank
you everyone for all the work. Looking forward to 6.0 and all the
security stuff yay. I hope the apps I use that their maintainers adopt
the changes.
alwillis wrote 1 day ago:
> Homebrew is the first thing I install on a new Mac.
Absolutely!
IgorPartola wrote 2 days ago:
Is Homebrew still tied to GitHub or has there been any move to provide
redundancy across multiple providers?
Also coming from what I consider traditional package managers such as
apt, rpm, emerge, pkg, etc. I am still confused on cans, taps, kegs,
formulas, etc. Does anyone have a good and concise guide to what all
these features are?
petetnt wrote 2 days ago:
Homebrew 6.0.0 seems to be the first major version of brew that is
heavily written using AI. Thereâs new document at [1] that was added
11 hours ago. Do you think that these guidelines have been followed
consistently since 5.0.0?
HTML [1]: https://docs.brew.sh/Responsible-AI-Usage
mikemcquaid wrote 1 day ago:
I would say Iâve embraced AI most heavily and I wrote this document
so: yes.
I review AI written code on Homebrew the same way I review code from
a no avatar GitHub user with no previous contributions.
The experimental and abandoned brew-rs frontend was more âvibe
codedâ using my knowledge of how to benchmark and test homebrew
accurately and with a shitload of manual testing. Maybe thatâs why
the performance wasnât as good as expected, who knows.
awesome_dude wrote 2 days ago:
Dependency management is still one of the hardest jobs in systems
(languages, Operating systems, distributed applications, etc) - hat's
off to you and your team for the hard work keeping everything together
orsenthil wrote 2 days ago:
Thank you. It is just funny and interesting to note people seeing
Homebrew as their choice of default package manager on linux! It shows
that people clearly care about the technically better solution which
has a very good UX over the native choices that linux distros made over
years, be it apt or yum or something else.
I install homebrew as a first thing on my corporate amazon linux too as
many system packages are lacking, and I couldn't get neovim in a
different way.
tommica wrote 2 days ago:
Such an amazing project!
whinvik wrote 2 days ago:
I love using Homebrew but I wish there was more support for pinning. I
recently setup a new remote VM and tried to use a Brewfile for my
setup. Turns out I cannot pin Neovim and so had to force upgrade my
setup to 0.12.
Forced upgrades are not nice.
mikemcquaid wrote 2 days ago:
Try `brew version-install` (which uses `brew extract` and `brew
tap-new` under the hood)
Hamuko wrote 2 days ago:
I don't understand how the tap trust improves security at all. If I'm
installing something from a third-party tap, instead of running tap +
install, I now run tap + trust + install? How does this protect me
against compromised taps?
mikemcquaid wrote 1 day ago:
You can now trust individual files inside taps. It was not clear to
all users before now that some commands (before â-eval-all, a mess
this replaces) would evaluate all packages Ruby code from all taps).
This cleans that up and some other security degrading edge cases I
wonât bore you with here.
Trust is also user specific now.
Itâs not a silver bullet but it does help address some potential
attacks and gives us a foundation to improve on over time.
thealistra wrote 1 day ago:
Exactly - so far seems like a windows vista âare you sure?â
Modal. Are we missing something here?
egorfine wrote 2 days ago:
> The master to main migration begun in 4.6.0 continues: more
repositories no longer update master, GitHub Actions warn @master users
to migrate to @main and the sync-default-branches workflows are removed
Speaking of important things.
12_throw_away wrote 2 days ago:
Well, I might as well ask my tech support question here :)
I just ran the upgrade to 6.0.0, and it downloaded so many things
concurrently that it killed my wifi (old router). Is there a way to cap
bandwidth or maximum concurrent connections? (this is something I have
to do in many download heavy apps, e.g., steam)
grosswait wrote 1 day ago:
You could use network link conditioner to artificially limit, or one
of the apps that can enforce per app limits such as tripmode
srik wrote 2 days ago:
I don't think homebrew allows throttling bandwidth but it does let
you set maximum concurrent downloads though. I believe the default is
twice number of cores; you must have quite a few :) Set this to your
preference:
HOMEBREW_DOWNLOAD_CONCURRENCY
eikenberry wrote 2 days ago:
Does anyone know of a good comparison of the process to add a package
to the system? I've used multiples of these sorts of user-land package
managers and always find tools that aren't in the repositories that I
have to install manually. It'd be great to just add these tools to an
existing package manager but I've never seen this aspect of these
package managers compared.
theragra wrote 2 days ago:
Comparison of which managers?
Adding package to homebrew is straightforward, except that it has a
lot of (reasonable?) requirements to make it right. Basically, you
make a PR with a "formula" to their main repo from your branch.
Formulas are ruby programs. LLM can do it easily, and such code is
accepted if correct.
eikenberry wrote 2 days ago:
Homebrew, mise, flox, devenv are the first ones I can think of..
Arch Linux's AURs get an honorary mention as they are used in the
similar way on that distro and Arch + distrobox gets the same
results. A quick search shows there are many others but it doesn't
look like a comparison exists for this area and I'm getting OK
results out of AI comparisons. I'll just dig into it that way.
theragra wrote 3 hours 26 min ago:
I think homebrew is different in comparison to flox,mise and
devenv.
Later are for reproducible dev envs, former is for installing
tools globally where you cannot/do not want traditional package
managers or building from source.
pdntspa wrote 2 days ago:
Does this handle macOS installs with multiple local users? I have to su
into account 1 if I want to brew install something from account 2
mikemcquaid wrote 1 day ago:
brew as-console-user may help here. We donât support a multiuser
setup so there may be some limitations but we try our best to address
problems as they come up.
JimDabell wrote 1 day ago:
Is there more documentation than this?
> as-console-user command [args â¦]
> Run a Homebrew command as the active macOS console user.
> This is intended for MDM, Munki and Jamf workflows where brew is
invoked as root but Homebrew operations should run as the logged-in
console user. The nested command is always dispatched through
HOMEBREW_BREW_FILE.
â [1] This isnât very informative. Is there more documentation
somewhere else that Iâm missing? Google search doesnât really
find much.
I currently have a dedicated `homebrew` user that I access with
`alias brew='sudo --set-home --user=homebrew --chdir
/Users/homebrew -- brew' but itâs got a number of shortcomings.
What will as-console-user do differently to this?
HTML [1]: https://docs.brew.sh/Manpage#as-console-user-command-args-
frizlab wrote 2 days ago:
Thanks for your hard work!
I discovered Homebrew now sometimes asks whether I actually want to
install a formula (e.g. `brew install ffmpeg` asks whether I want to
install it because it has dependencies). Is there a way to disable this
behavior and revert to the previous one?
mikemcquaid wrote 2 days ago:
Thanks :)
â-no-ask, â-yes, -y or HOMEBREW_NO_ASK=1
frizlab wrote 2 days ago:
Nice, thanks!
Added to my configuration file :)
HTML [1]: https://github.com/Frizlab/frizlabs-conf/blob/663e287eadad...
golem14 wrote 2 days ago:
For those of us who use homebrew today, how do we get the new cool
benefits ? Is there a command to upgrade (like ```brew upgrade```)
everything to the new hotness, do we need to uninstall everything and
reinstall ?
It's probably discussed somewhere but didn't find when glancing at the
OP.
m0do1 wrote 2 days ago:
there is `brew update`
golem14 wrote 1 day ago:
sure, but is that doing the same as deleting all installed sw and
then reinstalling it using the new safeguards?
Assuming I have already installed something homebrew 6 would not
let install, will I get a warning?
golem14 wrote 1 day ago:
I tried brew upgrade on my setup, got a bunch of warnings about
untrusted taps, and it upgraded what it could, and updated itself
to homebrew 6.0.0. So I guess, yay ?
satvikpendem wrote 2 days ago:
Thank you for your work on Homebrew, I use it every day. On the matter
of speed and parallel downloads, how does this release compare to
Zerobrew [0]?
On another note, to commenters here, I've been using brew bundle with
the Brewfile more and more these days as a declarative list of all user
packages installed, should I just move to Mise or Nix instead? What are
the benefits and drawbacks? Last time I used Nix on my MacBook a few
years ago it seemed to brick my whole system so not sure what that was
about.
[0]
HTML [1]: https://github.com/lucasgelfond/zerobrew
JamesSwift wrote 2 days ago:
Most nix users still use brew for casks on mac. Using brew bundle as
your interface to it makes things almost seamless, so its not too
icky overall.
eg I manage my Brewfile declaratively with home-manager, and then run
this on file change
HOMEBREW_NO_UPDATE_REPORT_NEW=1 HOMEBREW_NO_AUTO_UPDATE=1
brew bundle --file="$HOME/Brewfile" --cleanup --no-upgrade
holysantamaria wrote 2 days ago:
I will try this new release of brew but I have been extremely satisfied
with determinate nix so far. It completely changed my confidence in
installing new stuff
mattbettinson wrote 2 days ago:
Okay, but can you reverse a binary tree?
yesitcan wrote 2 days ago:
We should all be ashamed of the interview culture we have created in
this industry.
mattbettinson wrote 2 days ago:
I didn't do shit :D
napolux wrote 2 days ago:
did google apologize for not hiring you?
mikemcquaid wrote 2 days ago:
Youâre thinking of mxcl, the creator, not me.
I also applied and failed a final stage job interview at Google (and
various other places over the years) but never really bothered me
that much.
Ironically I think Iâd probably never have started working on
Homebrew if it had.
napolux wrote 2 days ago:
oh sorry i was wrong, glad it happened then, and thx for your work!
mikemcquaid wrote 1 day ago:
No apologies needed thanks for the kind words! <3
airwarmedd wrote 2 days ago:
damn, I can't believe, it's still getting updates. found out homebrew 6
months ago, I'm awe! amazing product
nosioptar wrote 2 days ago:
I used OSX for about a year about 10 years ago. Homebrew was what made
it worth using OSX. Thanks for all the effort put into homebrew.
I'd use it today on Linux, but I'm pretty anal about only using
software from the distribution repos (or compiled locally if not
available.)
terminalbraid wrote 2 days ago:
How do you square advocating for the "Open Source Resistance" which
touts "stop asking for permission" to do software and then saying "we
need everything on MacOS to be signed and will be dropping packages
that don't get Apple's permission"?
I'd consider donating, but I find that behavior to be part of squeezing
free computing and participating in and advocating for the corporate
erosion of ownership of one's hardware environment.
mikemcquaid wrote 1 day ago:
I square them because both of them allow me to do lots of open source
work and enjoy it.
Your signing point is not accurate. It doesnât apply to all
packages, only casks in the official tap. With casks the trust model,
particularly on things that auto-update and donât expose versions
or checksums on download URLs, heavily relies on Appleâs security
guardrails. We pushed against them for a while but Appleâs
direction of travel made it clear that it was a waste of our energy
and that we were at risk of compromising our users through doing so.
You can still automatically remove quarantine in third-party taps as
desired, weâre just making it less easy to do so because we
consider it a security feature that should require a deliberate
bypass.
I donât think anyone is obliged to donate to Homebrew but this sort
of framing, assuming you use Homebrew, isnât great. If you find
what we do morally distasteful: go use something else. MacPorts, Mise
and Nix are all good. This will be better for everyone than using us
begrudgingly.
zamadatix wrote 2 days ago:
OSS Resistance is about not asking for time to do something yourself
while removal of unsigned casks is about what they host in the
official Homebrew/cask repo. You're free to make & use your own tap
to use with Homebrew without asking, so there's not really anything
to square between the two stances - any conflict all comes purely
from your 3rd stance about signing in general.
I just threw them a small donation for supporting this software for
so long, even if it's only 98% how I'd want the project to be run all
these years myself.
maxloh wrote 2 days ago:
Homebrew is so good that I use it on Linux whenever possible.
Most Linux package managers cannot separate user-installed packages
from system packages. This makes cleaning up your workstation nearly
impossible and a pain in the ass, since you can't tell what should be
removed, or more importantly, what can be removed.
Also, most native package managers update much slower than Homebrew,
meaning you often only get outdated packages.
SomeHacker44 wrote 1 day ago:
Curious about this. Usually I try to get an Apt source (I use
Ubuntu). Why would I want to use brew on Linux? I stopped using Macs
and brew around 2018 when Apple started closing down it's macOS for a
few years and got sick of it. Thanks!
thiht wrote 1 day ago:
> around 2018 when Apple started closing down it's macOS
Did I miss the memo?
saghm wrote 2 days ago:
> since you can't tell what should be removed, or more importantly,
what can be removed
Isn't that what dependency detection does? Whenever I'm not sure if
something can be removed, I just try to remove it, and if it would
break something else, the package manager tells me. I can broaden my
scope and see if that's also an unnecessary dependency for something
and follow the chain, with it eventually ending up with a set of
packages where I actually get the prompt to proceed or not (meaning
nothing in it is a required dependency for anything remaining), or I
see a package I definitely want to keep around and stop. If I'm
interested in what's part of the base system, I just check the
metapackage for the base system.
This doesn't sound like something that's a problem with package
managers in general compared to maybe some distros just using them
poorly.
e40 wrote 2 days ago:
Just want to thank you, Mike. I love Homebrew and wouldn't know what
to do without it. My company sponsor's the project on github and I
recommend that everyone consider helping out.
mikemcquaid wrote 1 day ago:
Thanks for the kind words and sponsorship <3
jwr wrote 2 days ago:
Thanks for all the work you put into this over the years. Homebrew
became my go-to solution for installing software on my Macs (after
MacPorts) and I just realized that someone has been doing all that work
for me for so long. Much appreciated!
shevy-java wrote 2 days ago:
Has anyone tried it on Linux? It has been several months
since I last tried it on Linux. I found some things worked
but others did not. Has anyone more recent experiences here,
say, within the last 6 months, on Linux specifically?
I am using my own custom "package" manager in ruby, but
naturally it is nowhere near as sophisticated as homebrew.
I am looking more towards complementing this, but these days
I also lack time for more thorough testing, so I try to
minimize pain points (and thus also less frequently use
software written by others for the most part, unless it
is a key project such as libreoffice and what not).
theragra wrote 2 days ago:
Wdym tried?
There are many thousands of users of Linux homebrew, mostly users of
atomic distros. I am one of them. I was so happy using homebrew that
I've added new formula to its repo, far2l-tty
covratools wrote 2 days ago:
Thank you!!
chuckreynolds wrote 2 days ago:
Brew is so good... just sponsored on github. Thanks for the hard work!
sebiw wrote 2 days ago:
Shoutout to all the people making Homebrew possible! You rock! Everyone
should consider donating to the project:
HTML [1]: https://opencollective.com/homebrew
paulddraper wrote 2 days ago:
I tried hosting a homebrew tap, after hosting apt and yum repositories.
That was when I realized Homebrew is much, much harder.
Your server needs to implement the git protocol. You can't just stick
it on some server with a CDN in front of it, you need to run and
fortify a git server.
Strange choices IMHO.
theragra wrote 2 days ago:
I think it is focused on GitHub. It might not be suited for many
people this way, but it works well. Opionated design.
paulddraper wrote 1 day ago:
Well no one ever had issues with GitHub.
riffic wrote 2 days ago:
happy Bluefin Linux user and can vouch that the Homebrew experience in
Linux is great as well. Really excited for where things are going.
klodolph wrote 2 days ago:
I recently switched back to Homebrew from Nix, and the three big
factors in that switch are:
- Brew seems to have better support for the packages it has, compared
to Nix where it seems a percentage of packages are not as well
maintained,
- Better Mac support; some Nix packages have features disabled on
macOS, I think just because the maintainers of this packages donât
have a Mac for testing,
- Better UX.
Obviously I miss the reproducibility of Nix environments and the
ability to easily create my own flakes with specific packages, but on
the balance, Brew has won me back. (I still like Nix, and FWIW we use
Nix at work.)
commandersaki wrote 2 days ago:
I was interested in Nix because it could automate setup and
configuration of macOS features. But all it does is usually run
defaults or some intermediatary. In the end I stuck with brew and
wrote an idempotent setupmac() function in my bash_profile (I use
bash 5) with the aid of chatgpt since it knows all the cool defaults
commands, and itâs pretty much solved setting up a new account or
mac (alongside a Brewfile I maintain in my dotfiles). I donât need
any of those highfalutin tools.
klodolph wrote 2 days ago:
I am, like, two minutes away from getting my configuration back on
a fresh Mac or Linux system without Nix, so configuration
management is just irrelevant to me. I am evaluating it as a
package manager and a way to setup development environments.
Fethbita wrote 2 days ago:
I use nix-darwin and also manage my homebrew packages with it. Maybe
you can take a look at that.
May I ask for what do you use it at work? I have a few places I think
nix might suit but I canât really put my finger on it.
klodolph wrote 2 days ago:
Iâm not sure what I would get out of nix-Darwin. It looks like it
does not solve any of the problems I am trying to solve? I donât
need or want configuration management on my personal systems,
except for the web servers, which I manage using Terraform and
Ansible (I am happy with these).
We use Nix at work for all sorts of stuff. Binaries run in
production from Nix paths. Software we build has dependencies in
Nix. People on workstations run commands from Nix paths. The OS is
not Nix, but the Nix package manager looks like itâs on its way
to consuming most of our dependencies. It is not used for building
or deploying our code, though.
mikemcquaid wrote 2 days ago:
Very glad to hear this, thanks for posting.
shawkinaw wrote 2 days ago:
Could really use a good rollback mechanism, is there one in the works
perchance? I have broken my home server multiple times with bad
InfluxDB and Grafana updates, and rollback was a huge pain. Iâve now
disabled cleanup so old versions of packages are kept, but there must
be a better way.
jamesgill wrote 2 days ago:
I know this runs on Linux too. As a Linux user, I'm unclear on why I
might use this instead of apt or dnf, for example. Any Linux users out
there have experience with both Homebrew and one of these?
DCKing wrote 1 day ago:
It's for predictability in upgrades. Homebrew allows you to separate
system packages (from apt or dnf) from user packages (from homebrew)
[1]. Running apt upgrade or dnf upgrade can render your system
unbootable if you're unlucky (or unstable or degraded if you're less
unlucky). Running brew upgrade can at worst break some of your own
user's setup or tools.
Since everybody runs their own unique permutation of apt or dnf
packages, adding as little as possible will keep you as close as
possible to what distro maintainers test. There's even OSes like
Fedora Silverblue or Bluefin or SteamOS that ship with a fully baked
_image_ - where installing system level packages is strongly
discouraged - which helps ensure predictability and stable
upgradeability.
Homebrew packages also tend to be more recent (this depends on your
distro of course) and don't require elevated permissions to install.
[1]: Other unprivileged package managers like Mise or Nix do the same
of course
analog_daddy wrote 1 day ago:
Yes. I daily drive pop os now. Hate to use flatpak for anything. Only
install core packages, google chrome and vscode using apt. Almost
everything else is installed using homebrew. The idea is have a base
stable system for UI and basic shell. Usually get the latest packages
from brew. Earlier same base system but had distrobox with arch
toolbox. Planning on using this scheme going forward, especially
since while I love rolling release, they sometimes might have
regressions which I donât want to deal with right away. And these
regressions can be both at system level or user packages level.
Having a stable base helps significantly in daily driving linux in
real world.
theragra wrote 2 days ago:
You can have multiple versions of tools installed. But overall,
homebrew plays well with atomic distros. They are thing in itself,
yet getting more popular lately. Im using them at home and on the
server, and it feels calmer, because I can't fuck up whole system
easily. Considering I'm using llms without sandbox often, this is
pure gold.
latexr wrote 2 days ago:
You can run Homebrew on Linux without admin privileges. Useful e.g.
for shared hosting.
analog_daddy wrote 1 day ago:
Small note: You need admin privileges only once for the first
install which creates a new user `linuxbrew` and everything is
based around `/home/linuxbrew` prefix. The issue is on systems
where getting an admin access is not possible, you cannot
âreliablyâ install to a different prefix. It is currently
unsupported.
Honestly, I would settle for a custom prefix if it tells me exactly
what packages will break and what wonât without having to read
each and every formula recipe.
Thatâs one thing that bothered me for a while and I did not have
the willpower to explore that direction without having community
support.
riffic wrote 2 days ago:
Homebrew provides access to a massive catalog of software, including
many tools that are not packaged for Fedora, Debian, or Ubuntu.
Homebrew relies on a high level of automation in GitHub actions,
which ensures users get the latest versions of tools quickly, rather
than waiting for distribution-specific repositories. The Homebrew
approach also decouples the underlying system from what you choose to
install in user-space.
phplovesong wrote 2 days ago:
Does homebrew still do that insane thing when you want to upgrade a
single package it tell you "hold my beer" and starts installing
postgres and some obscure python version?
mikemcquaid wrote 1 day ago:
This behaviour came about because, before we did that we ended up
upgrading just what you wanted and breaking other packages by
mistake.
Itâs taken a long time but weâre finally at the point where we do
(pretty much) only upgrade the minimal software we need to actually
avoid breakage rather than the previous âbetter safe than sorryâ
conservative approach. We also now tell you by default everything
weâll upgrade before we do it (unless you say âupgrade fooâ and
all we are gonna do is upgrade foo).
So: weâve maybe solved this issue and maybe not. The perfect
outcomes for everyone here is pretty much impossible given the
original design of Homebrew. MacPorts or Nix or Mise are likely a
better fit in that case.
lkbm wrote 1 day ago:
Are you referring how it does a `brew upgrade` when doing a `brew
install`? It should tell you how to disable that whenever it happens:
> Adjust how often this is run with `$HOMEBREW_AUTO_UPDATE_SECS` or
disable with
> `$HOMEBREW_NO_AUTO_UPDATE=1`. Hide these hints with
`$HOMEBREW_NO_ENV_HINTS=1` (see `man brew`).
shikck200 wrote 1 day ago:
Why is this not the default? I removed homebrew years ago, because
it was just full of nasty surprises like this. Does homebrew still
share dependencies? Previously you could not have package A with a
transitive dependency of lib-X = v1.2 and B that requires lib-X =
v.0.7.
philistine wrote 2 days ago:
The deprecation of Intel support is agressive! Every Mac enthusiast I
know who uses a Mac as a server uses their old machines, which are
pretty much all Intel. We'll lose support from you guys a year before
Apple!
I know supporting Intel is an ordeal and a choice, but I'm firmly on
the camp that Homebrew should find a way to maintain Intel support as
long as possible.
mikemcquaid wrote 1 day ago:
> We'll lose support from you guys a year before Apple!
Homebrew will still work (increasingly poorly) on macOS Intel for a
year after that, it just wonât be âsupportedâ or tested in CI
environments (where currently macOS Intel usually slows down the
release of lots of software for all other platforms).
That a volunteer run project with no employees is unable to come
anywhere near the support levels of the worldâs second biggest,
trillion dollar company should not be surprise.
Weâre also limited that GitHub (part of Microsoft, 4th biggest,
also trillion dollar company) will have killed all macOS Intel CI by
autumn/fall 2027 too.
We are announcing this well in advance to give people migration paths
to MacPorts or other hardware.
Thereâs nothing stopping you for doing the work to setup
âIntelbrewâ and support it for the community. When I started work
on Homebrew it had no funding or CI or binary packages/bottles at
all. I did much of that work myself. It was hard but you could do the
same.
Completely reasonable to say âI donât have time!â but: then you
need to accept the decisions of those that do, sorry.
philistine wrote 1 day ago:
That's a very reasonable answer thank you.
daeho-ro wrote 1 day ago:
AFAIK, github action runner for intel will be deprecated at similar
period, maybe that is major reason.
JSR_FDED wrote 1 day ago:
Does brew gather statistics that could show what portion of users is
on Intel vs Apple Silicon?
mikemcquaid wrote 1 day ago:
[1] From people who havenât disabled analytics.
HTML [1]: https://formulae.brew.sh/analytics/homebrew-os-arch-ci/30d...
srik wrote 2 days ago:
A saving grace is they're perfect for linux distros.
saghm wrote 2 days ago:
> We'll lose support from you guys a year before Apple!
If only Apple put a fraction of its resources towards maintaining
something like homebrew (or paying the people who do), maybe the
situation would be different.
frumplestlatz wrote 1 day ago:
MacPorts supports everything all the way back to 10.5/powerpc.
saghm wrote 1 day ago:
That's impressive, but I'd be reluctant to criticize one open
source maintained effort for not having parity with another when
it's all volunteer-driven. My point was that Apple is an insanely
profitable company with resources that are effectively unlimited
compared to what Homebrew has (and presumably likewise when
compared to Macports), so the initial framing of "this will stop
being supported before Apple" seemed pretty silly to me.
mrpippy wrote 2 days ago:
At this point that would be a 2018 Mac mini, which can only run
Sequoia (which will be out-of-support at the same time as Homebrew
drops Intel support).
If you want Intel support, MacPorts still runs back to Leopard.
yreg wrote 1 day ago:
And all 27" iMacs.
philistine wrote 1 day ago:
My server is an old mac we've upgraded. My home server is an iMac.
sunaookami wrote 2 days ago:
Yeah they also removed support for --no-quarantine flag :/ I only use
it for a few casks nowadays and try to avoid Homebrew as much as
possible. For CLI stuff I use Nix, Home-Manager and Nix-Darwin.
JamesSwift wrote 2 days ago:
Well nix and devenv are also dropping intel mac support due to
apple cutting off support : (
stouset wrote 2 days ago:
If anything, the overwhelming majority of Apple enthusiasts have gone
all-in on Apple Silicon. I sincerely doubt those using old Macs as
servers are anything but a rounding error.
asdff wrote 2 days ago:
Maybe among the general mac population they are a rounding error.
But among the mac population who actually peeks behind the curtain
and uses homebrew?
stouset wrote 2 days ago:
Yes, to such a stunning degree that Iâm having a hard time
believing youâre serious. The M1 was utterly transformative.
The install base of homebrew is enormous. The proportion who are
keeping old Mac hardware around as home servers is minuscule. The
proportion of those who are keeping old Intel Macs are a fraction
of that, and the ones who arenât just running Linux on them are
yet another fraction.
Thatâs not to say youâre crazy or anything. You do you. But
do understand that you almost certainly constitute a nearly
irrelevant minority of users of homebrew.
jdiff wrote 1 day ago:
From elsewhere in the thread, some hard numbers on the topic.
[1] Intel homebrew is larger than Linuxbrew, yet I think it'd
be shocking if they dropped support for Linuxbrew.
Old machines still work. They're still deeply useful. I'm still
using daily an Intel Macbook with homebrew on it. When I no
longer use it daily in some years more, it'll still make a
perfect server.
HTML [1]: https://formulae.brew.sh/analytics/homebrew-os-arch-ci...
jrmg wrote 2 days ago:
Maybe Iâm just biased because itâs what Iâve done
personally, but almost everyone using an old Intel Mac as a
server is surely running Linux?
brigandish wrote 1 day ago:
Which Linux are you using for that?
jrmg wrote 1 day ago:
Debian.
asdff wrote 2 days ago:
If your clients are all macs it is just nicer keeping the
server on macos imo. mac os is unix after all so you don't have
any software incompatibilities for tools you'd probably run on
the server. Time machine support on the server is built in,
instead of being a sort of hack with samba if you wanted to try
and run it on a linux server. I haven't messed with it much but
there might be some clever stuff you could do with applescript
and triggered actions, maybe schedule your compute jobs from
your calendar app for example.
frollogaston wrote 1 day ago:
I held onto a 2010 Mac mini server for like 11 years before
retiring it due to hardware problems (blame the hot room).
Time Machine is the only thing I can think of that was still
relevant at the end, and even that you can do with any NAS
supposedly. The macOS Server stuff was way eol, and anything
worth keeping had better Linux equivalents.
dlandis wrote 2 days ago:
Is it true that contributors to homebrew need to know how to invert a
binary tree?
artyom wrote 2 days ago:
Not sure if everyone is going to get your joke, but it's a very good
one.
qyron wrote 1 day ago:
Can you explain the joke?
y1n0 wrote 1 day ago:
HTML [1]: https://news.ycombinator.com/item?id=9695102
dionian wrote 2 days ago:
homebrew is so nice, thank you for all your effort
threecheese wrote 2 days ago:
I assume this trust issue is related to the not-infrequent MacOS
notifications asking for permission to run Ruby in the background or
when the machine starts. It says nothing about Homebrew though.
tom1337 wrote 2 days ago:
macOS Permission Management regarding shell scripts is so bad. For
example they show you a list of software thats allowed to access the
full disk - but I have like 8 "sh" or "bash" in there and some random
scripts with no way to open the enclosing directory in Finder making
it basically impossible to see what it is and if its legitâ¦
mh- wrote 1 day ago:
I'm not sure when they added it, but I just checked again in macOS
26 and you can right click on those sh-like entries now and hit
Show in Finder.
ch-bas wrote 2 days ago:
Thanks for the hardwork.
let_rec wrote 2 days ago:
Does Homebrew have good support for exact (and older) versions of
packages now?
andrewaylett wrote 1 day ago:
I'll second the recommendation for `mise`, and add: I typically use
Homebrew for things I want everywhere, and if I want something
everywhere then the latest version is _probably_ OK. I typically use
mise en place for versions which are project-specific.
So I have a system Python (largely unused), a Homebrew python (pulled
in as a dependency, I won't use it), and as many different mise/uv
Pythons as I need for different projects. Similarly NodeJS and Java.
I'd given up on nvm a while back, no longer use pyenv, and mise and
uv work together really nicely.
mikemcquaid wrote 2 days ago:
`brew version-install` may do what you want here.
PufPufPuf wrote 2 days ago:
Nope, still rolling. Have a look at [1] if you need exact versions
HTML [1]: https://mise.jdx.dev/
c-hendricks wrote 2 days ago:
I don't think that's a part of its goals at all.
pknerd wrote 2 days ago:
Thanks for producing such an amazing piece of software. Most of my Mac
installations are based on Homebrew, but I have to rely on version
management tools like Pyenv or nvm for Python and Node. Wish there was
some standard 'Homebrew' way to install multiple versions of node, php
and Python
midenginedcoupe wrote 1 day ago:
I switched from brew to [1] for this very reason.
I don't understand how devs don't use a tool that makes multiple
versions of everything possible.
HTML [1]: https://asdf-vm.com/
mikemcquaid wrote 2 days ago:
There's a selection of ways that may or may not work for you:
- `formula@version` packages
- `brew version-install` (which uses `brew extract` and `brew
tap-new` under the hood)
- `version_file:` support in `brew bundle
- `brew pyenv-sync`
PufPufPuf wrote 2 days ago:
Have a look at [1] , it's exactly what you're looking for!
HTML [1]: https://mise.jdx.dev/
swingboy wrote 2 days ago:
Interesting that the `brew-rs` experiment has concluded and didn't find
much of a performance increase. I suppose that is expected though with
a lot of the bottleneck being network IO?
swiftcoder wrote 2 days ago:
Congrats on the performance improvements. That's the most pleasant
`brew upgrade` session I've had in years
hk__2 wrote 2 days ago:
Hi Mike, Iâm @bfontaine on GitHub (I helped maintain Homebrew in
~2014-2016). Iâm always impressed at your longevity as a maintainer;
itâs been like what, 16+ years youâve been maintaining Homebrew and
youâre still here, still shipping new features! Thank you for
everything!
maxloh wrote 2 days ago:
Homebrew is so good that I use it on Linux whenever possible.
Most Linux package managers cannot separate user-installed packages
from system packages. This makes cleaning up your workstation nearly
impossible and a pain in the ass, since you can't tell what should be
removed, or more importantly, what can be removed.
Also, most native package managers update much slower than Homebrew,
meaning you often only get outdated packages.
mayama wrote 1 day ago:
My personal solution for this is to install a simpler distro in
chroot, alpine, and install dev newer apps in to it. Additionally,
I run chroot via bwrap sandbox and have been doing this for quite
some time now before flatpak became famous.
iamcreasy wrote 1 day ago:
> Most Linux package managers cannot separate user-installed
packages from system packages.
What is the use case when someone would want to differentiate
system/user installed package? Isn't it good things that they are
the same - meaning once something is install - it is there
regardless of how it got here.
curt15 wrote 1 day ago:
Devs shouldn't need root access to install tooling or
dependencies for a project.
Mixing user and system software is like having Photoshop and all
of your games install their files directly into the Windows
directory.
wolrah wrote 1 day ago:
Two reasons come to mind for me:
1. It's very common, especially in certain ecosystems like
Python, for the system to depend on old versions of things in
such a way that updating to modern versions will break your
entire system, while at the same time you want to run something
at the user level that depends on a newer version. The solutions
to this are usually ecosystem specific and often annoying to use
for someone who just wants to run a program (again a great
example being Python venvs, which at this point have decades of
tooling built up around trying to make it less annoying to deal
with).
2. For "cattle" systems having everything installed at the system
level is generally not too much of an issue, but for "pet"
systems where the user might be experimenting with things it's
really nice to be able to install stuff in a way that doesn't
affect anything outside of your user account even if it's also
available at the system level. The computers that I personally
operate from on a daily basis tend to build up a lot of crap I
used once over time and removing it without just backing up my
stuff and nuking it all can be a major pain.
robotresearcher wrote 1 day ago:
The last-millennium solution to me-only installs is to put
stuff in $HOME/bin, $HOME/lib, and $HOME/etc, and put those in
the appropriate paths. Build the package with e.g.
CMAKE_INSTALL_PREFIX=$HOME. At some point I switched to putting
those dirs all in $HOME/opt for tidiness.
It's worked for me since workstations were shaped like pizza
boxes.
I'm sure there are some things it can't do, but it goes a long
way. When you're installing distributed binary packages you
have less ability to control the baked-in install dirs, but if
the package honors the conventional $(env) it can work.
noisy_boy wrote 1 day ago:
I had this exact situation with Citrix workspace refusing to
install after my upgrading to the latest Fedora. I had to force
install and things did work but I would have preferred to not
having to do that. I don't know enough about Homebrew to know
if it would have helped (Citrix distributes .deb and .rpm
files).
giancarlostoro wrote 1 day ago:
Honestly for python just using uv is enough, not only does it
handle virtualenv for you, it will also install the necessary
python version you need locally.
manwe150 wrote 1 day ago:
Thatâs entirely a user package manager though and is GPs
point: what uv does cannot be done in a package manager like
apt which sees itself as only doing system package
management.
selicos wrote 1 day ago:
In my current use case I'm setting up a new Ubuntu server for
hosting LLMs. I didn't take notes when setting it up last time
around but want to document exactly what was required to pass on
to coworkers trying something similar. I don't know what packages
I installed to get the minimalist setup working vs what is
installed by default. I'm tempted to nuke and redo with notes but
I'm sure there is a better method of tracking down what I
deployed to get to the current state.
...or not, and this is why HomeBrew exists and I need to learn it
or ansible/etc.
maxloh wrote 1 day ago:
You can try this command. But I doubt it will work as intended
if you have ever upgraded Ubuntu versions.
comm -23 <(apt-mark showmanual | sort -u) <(gzip -dc
/var/log/installer/initial-status.gz | sed -n 's/^Package: //p'
| sort -u)
HTML [1]: https://askubuntu.com/a/492343/1056703
michaelmrose wrote 1 day ago:
NixOS seems ideal for this.
dom96 wrote 1 day ago:
Huh, didn't know you can use Homebrew on Linux
c-hendricks wrote 1 day ago:
Even has Linux aarch64 bottles!
colordrops wrote 2 days ago:
Brew is probably serving your needs, but you might also want to
look into Nix/NixOS, which takes what you are talking about to the
next level.
analog_daddy wrote 1 day ago:
Yeah I tried nix about 8 months ago. Not really as simple as
homebrew. Even the detereminate nix tutorial though nice felt too
much of a hassle. I feel homebrew really is a nice interface
which is pretty close to conventional package manager, while nix
even though the concept is revolutionary, felt lacking in user
experience. Hope the documentation improves.
vondur wrote 2 days ago:
Homebrew is the default on Bluefin Linux since most of the system
is immutable. I like it since Iâm so used to it on my Mac.
pram wrote 2 days ago:
Yep homebrew on an LTS distro is pro.
Washuu wrote 2 days ago:
> Most Linux package managers cannot separate user-installed
packages from system packages.
And because of pinning versions to LTS releases on certain Linux
distributions many times those packages stay out of date for years.
Which is quite annoying.
xenophonf wrote 2 days ago:
> quite annoying
It's also quite stable, which you'd think more people would prize
given the recent and on-going supply chain attacks.
thewebguyd wrote 2 days ago:
Stable as in unchanging, sure.
Stable can also mean "you get to keep all the bugs present in
this version for the next 4+ years"
jandrese wrote 2 days ago:
Or worse, the kernel moves beyond the package in the repo so
a year and a half later it doesn't even work anymore.
VirtualBox is really bad about this.
happyopossum wrote 2 days ago:
Given the recent dramatic uptick in vulnerability discoveries,
it's also prone to being quite insecure...
xmprt wrote 2 days ago:
LTS still typically get security updates. That's what the
support in long term support means.
moskimus wrote 2 days ago:
This gets thrown around a lot, but it's not entirely true.
Depending on the particular distro, only certain core
packages are likely to get updates on LTS releases.
Non-core packages may just get left to rot until the next
LTS release. Specifically Ubuntu follows this. A lot of
their non-core packages just get imported from Debian and
then just sit unmaintained until next release (this goes
doubly if not using Ubuntu Pro).
Milpotel wrote 1 day ago:
> Depending on the particular distro, only certain core
packages are likely to get updates on LTS releases.
All LTS distros fix only some core packages sporadically
as no one is able to back port all the patches esp. since
most packages do not use CVEs and just fix bugs on the
go. "Stable" for non-rolling distributions simply means
"horribly broken and outdated".
manwe150 wrote 1 day ago:
Itâs not horribly broken any more than your toaster
is for not needing constant updates. Though I do have
such a longstanding love/hate relationship with Ubuntu
because of this. It is why it runs everywhere and just
works (even powers the WSL2 defaults), but everything
it provides also always so very far behind I end up
recompiling so much important stuff by hand.
Milpotel wrote 1 day ago:
> Itâs not horribly broken any more than your
toaster is for not needing constant updates.
I don't know where this sense of "stable" in the
community comes from. Software isn't perfect and gets
fixed all the time. Yes, there are packages with
different maintained stable branches that you can pin
for your LTS distribution but this is by far the
minority. For the other stuff you constantly have to
work around missing features or existing bugs. E.g.,
why do I have to compile "jq" by myself just because
the outdated package crashes on certain inputs?!
shakna wrote 1 day ago:
The "outdated" package, probably has all these
security fixes [0]. That's why it exists - to
maintain something safely. You step back from
latest and greatest, to not get a compromised
system the next time something goes wrong.
[0]
HTML [1]: https://sources.debian.org/patches/jq/1.7....
Milpotel wrote 10 hours 58 min ago:
Nope, it hasn't because developers fix bugs along
the way without notifying package maintainers.
thewebguyd wrote 2 days ago:
Especially frightening when you look at how much everyday
stuff is actually in the Universe repo in Ubuntu. Without
Ubuntu Pro, your LTS system can sit in a very insecure
state for a long time as patching Universe is "best
effort" from the community.
Most popular GUI stuff is from universe, as are quite a
few dev tools. Some examples: Gimp, Inkscape, pip (and a
ton of python packages), most of gnome, a big chunk of
KDE, htop, mariadb, etc.
See for yourself grep -h "^Package:"
/var/lib/apt/lists/_universe__Packages | awk '{print $2}'
| sort -u
Or to see only what you have installed from Universe:
comm -12 <(dpkg-query -f '${Package}\n' -W | sort) <(grep
-h "^Package:" /var/lib/apt/lists/_universe__Packages |
awk '{print $2}' | sort -u)
A big repo isn't always better.
mikemcquaid wrote 2 days ago:
17 in September. Thanks for all your great work at the time! Hope
youâre well <3
kofj wrote 1 day ago:
thank you mike
thewhitetulip wrote 1 day ago:
At the off chance that you'll see and reply to my message, I have a
question
I saw a tweet by someone many years ago before I knew Homebrew was
a thing. The tweet basically said "Google rejected me for not being
able to invert a binary tree when 80% of Google engg use Homebrew"
Was that true?
bouke wrote 1 day ago:
That would be Max Howell @mxcl who started Homebrew:
HTML [1]: https://x.com/mxcl/status/608682016205344768
thewhitetulip wrote 1 day ago:
So the incident really happened lol
latexr wrote 1 day ago:
Ostensibly it did. But worth noting that despite many people
still thinking of Max Howell when they think of Homebrew, he
hasnât been there for a long long time. Pretty sure he
wasnât there at the time of that Google interview, even.
Mike and all the other contributors deserve much more credit
for Homebrew. There are even contributors who since left who
were there for longer and had a bigger impact than Max. And
he had nothing to do with the Cask part.
Unfortunately, Max still clings to having created Homebrew as
his greatest achievement, despite being so uninvolved for so
long that just about the only thing that remains of his is
the name and the beer nomenclature often confusing for
newcomers. Since then, heâs been aggressively chasing
whatever is popular at the time. When blockchain was all the
rage, the made a package manager that leveraged it. Now
heâs into AI stuff. But always, still at the top of his
website and plastered everywhere whenever he pursues a
project, he mentions he created Homebrew. [1] Seventeen
mentions of Homebrew on the homepage alone.
HTML [1]: https://mxcl.dev/
thewhitetulip wrote 1 day ago:
That page is insane
pjjpo wrote 1 day ago:
Gotten so used to brew, tap, etc never even thought how
unintuitive that might be for newcomers.
matsemann wrote 1 day ago:
Huh, I've never even considered that those words had
anything to do with beer. I've just accepted them at face
value, same as any other tech jargon.
latexr wrote 1 day ago:
The whole concept comes from homebrewing.
HTML [1]: https://en.wikipedia.org/wiki/Homebrewing
matsemann wrote 1 day ago:
Yeah, I guess it's not being a native English
speaker, so one just accept most of the words almost
as names without thinking about any other meaning the
word might have.
thewhitetulip wrote 11 hours 6 min ago:
For me it was just a command lol
It's now that I am reflecting back that it's all
related to home brewing!
leoedin wrote 1 day ago:
This page is kind of mad. [1] So much repetition. I'm
guessing it's targeting AI training sets? The guy really
wants you to know he created Homebrew!
HTML [1]: https://mxcl.dev/homebrew/
senderista wrote 15 hours 19 min ago:
Has to be targeting AI
colemannerd wrote 1 day ago:
Thank you mike!
cavneb wrote 1 day ago:
Thank you Mike!
trueno wrote 1 day ago:
just updated to 6.0.0. already loving `brew trust ` thank you for
all the years of work! practically a required macos experience for
me these days!
as far as cli utilities go the ux of homebrew has always been so
easy to use, honestly kind of a personal benchmark for me on how
repeatedly approachable it is, all commands are for whatever reason
so painless to remember. i remember when apple silicon dropped and
you guys followed shortly with support and the ability to switch
arches, like really killer stuff so impressed with homebrew! always
a treat when something im interested in tinkering with has a
homebrew formula available
alexgyurov wrote 2 days ago:
Thank you!
Kevcmk wrote 2 days ago:
Goat
vitorsr wrote 2 days ago:
Thanks for all the hard work.
We are not many [1], but Homebrew has been a great way to quickly
bootstrap an environment in immutable Linux distributions.
Note that certain operating systems such as Universal Blue's Bazzite
(1.28%), Bluefin (0.49%) and Aurora (0.28%) default to bundling
Homebrew [2]. [1]
HTML [1]: https://formulae.brew.sh/analytics/os-version/365d/
HTML [2]: https://github.com/ublue-os/brew
chid wrote 1 day ago:
I've been using it under linux and have been very (surprisingly?)
happy with how it runs especially when compared with current package
managers.
PufPufPuf wrote 2 days ago:
The concept of a "userspace package manager" is something I would
expect Linux to have figured out twenty years ago. It's ridiculous
that the usual situation for non-root users is "you can't install XY
but feel free to build from source". Homebrew, Mise and Nix are
filling that hole now. (Flatpak is more oriented towards GUI apps,
and Snap... exists.)
lanstin wrote 1 day ago:
I love brew but it was decades of tradition to download source and
compile as non-root on shared Unix systems. Not only were the
sysadmins skilled at saying no, they were not always available at 2
am, but installing some random code, after editing the Makefile to
reflect some oddity of something, was 24x7. And then when we got
better offers than shared dial up hosting, it was root or nothing.
To be sure it is ridiculous, but it is also traditional.
vitorsr wrote 2 days ago:
There is also the possibility of using Toolbx (formerly [Fedora]
Toolbox), distrobox or a container, and the underlying container's
package manager. The issue then ends up being about how ergonomic
it is to manage a separate guest system (and have to drop into it
anytime we wish to use a binary that is unavailable in the host).
PufPufPuf wrote 2 days ago:
I looked around and found this fun project -- basically "Arch Linux
in userspace on top of any other Linux":
HTML [1]: https://github.com/fsquillace/junest
sgarman wrote 2 days ago:
I'm a total noob in this space but I'm using pacman, paru, yay,
shelly. Are those different than "userspace package manager" or are
these not relevant because it's Arch?
hopw_roewur_ne wrote 2 days ago:
User, as in non-root/non-admin. Pacman, paru, yay, shelly ask for
root permissions.
mikepurvis wrote 2 days ago:
One of the frustrating limits historically with some of these is
that when you're already an unprivileged user it's been difficult
or impossible to get to a sandboxed environment to perform hermetic
or untrusted builds. So like with nix for example you could do a
user install and then builds would build as your user, but if you
installed as root, then builds would delegate out properly to
nixbld users.
This has gotten better in recent years with user namespaces but it
takes time for it to be adopted and achieve parity with what used
to be just jumping to a user who can only write to a newly created
dir in tmp.
bluebarbet wrote 2 days ago:
In Debian-Ubuntu it's become a standard pattern to use `curl` or
`wget` to add a third-party `deb` repo with keychain integration,
because for whatever reason there's still no `apt` command for this
obvious scenario. Really grinds my gears.
hoherd wrote 2 days ago:
That is not a "userspace package manager" though. That still
requires root.
chuckadams wrote 2 days ago:
Doesn't apt-add-repository do all that?
Arrowmaster wrote 18 hours 14 min ago:
It's not in Debian 13, the package was flagged with a critical
bug and was not fixed prior to release.
bluebarbet wrote 2 days ago:
For whatever reason, nobody seems to use it. It must be a good
reason or else they would. [PS: It's because it doesn't add the
signing keys and maybe also because it's too associated with
Ubuntu.] This, for example, is the official way to add
Mozilla's repo:
echo "deb
[signed-by=/etc/apt/keyrings/packages.mozilla.org.asc]
https://packages.mozilla.org/apt mozilla main" | sudo tee -a
/etc/apt/sources.list.d/mozilla.list > /dev/null
And here's Signal's instructions:
# 1. Install our official public software signing key:
wget -O- https://updates.signal.org/desktop/apt/keys.asc |
gpg --dearmor > signal-desktop-keyring.gpg; cat
signal-desktop-keyring.gpg | sudo tee
/usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null
# 2. Add our repository to your list of repositories:
wget -O signal-desktop.sources
https://updates.signal.org/static/desktop/apt/signal-desktop.so
urces; cat signal-desktop.sources | sudo tee
/etc/apt/sources.list.d/signal-desktop.sources > /dev/null
# 3. Update your package database and install Signal:
sudo apt update && sudo apt install signal-desktop
Bonkers.
Arrowmaster wrote 18 hours 9 min ago:
At least the signal one is using the new DEB822 format, but
whomever wrote that missed the fact they could have just
embedded the key into the sources file and it would be a very
simple command.
I'm fairly sure both of those are available from extrepo
making them a single short command away.
HTML [1]: https://manpages.debian.org/trixie/extrepo/extrepo.1...
thewebguyd wrote 2 days ago:
I believe apt-add-repository started out as Ubuntu specific
for their PPA system, didn't it? It's part of the
software-properties-common package.
When using it without a PPA (just giving in the repo URL) it
won't add the key by default, so you have to follow it up
with the wget -qO- https:/mykey.asc | sudo apt-key add - (<<
don't to this, apt-key add will add the key to the global
trust)
early days apt-add-repository also didn't support signed-by
for the signing keys. Very early on when you added some PPA,
it'd add the repo's GPG key to the global keyring, so you
were better off not using it anyway.
shevy-java wrote 2 days ago:
PufPufPuf wrote:
> The concept of a "userspace package manager" is something I would
expect Linux to have figured out twenty years ago.
Each one uses their own package manager right?
What I hate is that e. g. debian puts me to conform to their FHS. I
want things installed into versioned AppDirs. GoboLinux allows
that; NixOS to some extent too (though they used hashed directory
names). Debian does not allow me to do that. I don't want to
conform to what others wrote; I want software that adjusts to my
wants.
> Flatpak is more oriented towards GUI apps
Have they not recently added a mandatory systemd dependency? I
can't use software that things it must force software I don't need
or use onto me.
cosmic_cheese wrote 2 days ago:
At the very least, Linux package managers should have some concept
of different layers of packages.
For example, there might be layers for âsystemâ (core
components), âenvironmentâ (display manager, DE, etc), and
âuserâ, each of which are maintained fully separately so they
canât ever step on each othersâ toes and break things. Yes, it
means there will be some redundancy but for all the trouble and
complexity itâs saving I think itâs a worthwhile tradeoff.
chuckadams wrote 2 days ago:
Most "immutable" distro flavors do something like this. Back
when I ran Aurora, it was rpm-ostree for the core system packages
and homebrew in a devbox container for the rest. One incentive
for maintaining the layer separation was that rpm-ostree was
slow.
I've since moved my desktop box to NixOS, where everything is
just flakes, but my mac runs circles around it so it's just there
for Steam nowadays.
QuercusMax wrote 2 days ago:
I haven't looked much into snap but it seems very heavyweight from
the few things I've tried, which downloaded what looked like an
entire OS and filled up my disk and RAM. And the fact that you run
`snapd` to install a package is just... odd.
e12e wrote 2 days ago:
Well, there was stow/xstow... [1]
HTML [1]: https://www.gnu.org/software/stow/
HTML [2]: https://xstow.sourceforge.net/
shevy-java wrote 2 days ago:
Stow only symlinks. That's even one layer below GoboLinux, and
GoboLinux is not extremely active either (it is not dead, but
kind of semi-dormant, that is sometimes a few changes and
improvements are added, then it goes back to hibernation again).
LelouBil wrote 2 days ago:
I'm using nix on Bazzite, with home-manager
PufPufPuf wrote 2 days ago:
I have switched my full OS-level dev env to [1] from Homebrew+pipx+npm,
initially as an experiment but found out that it actually works
amazingly well. Many things get installed directly from GitHub releases
or a corresponding package manager (uv, pnpm, go get ...), zero glue
code to "repackage", zero version lag. You can install any arbitrary
version of a package, even multiple ones at once, and dynamically
adjust which ones are active per working folder or explicitly through
environments.
Funnily Mise does not support dependencies, and I was quite surprised
that it mostly doesn't matter, as either pnpm/uv handles that, or it's
a static binary that just works. In the past, had the unfortunate
experience of packaging a Python application for Homebrew (the
ridiculous process involved importing around 50 dependencies as
"resources", building every single one from source or manually checking
if it's already on Homebrew, declaring build toolchains for 5 different
programming languages as dependencies, waiting over an hour for CI to
finish on every update, then an upstream update introduced a
"build-time dependency loop" and the project suddenly became unpackable
for Homebrew) so I totally get why Mise took the "easy way out" and
just relies on language-specific package managers directly.
Only thing from my Brewfile that I couldn't replace was the Docker CLI
(needed to interact with Colima). And I still use Homebrew for casks. I
encourage others to experiment with their dev setups, there are some
amazing new tools out there.
HTML [1]: https://mise.jdx.dev/
dkarter wrote 1 day ago:
Mise does support docker cli - thatâs how I use it with Colima -
whatâs not working for you?
anhner wrote 1 day ago:
Last time I used it it was missing some features (like compose for
example), but nothing a LLM can't fix (needed just some
symlinking).
But it's not "it just works" yet.
port11 wrote 1 day ago:
Miseâs refusal to make global packages globally available is
off-putting. I keep using it for specific Node versions and the
integration with fnox.
The big drawback: having Claude complain every couple of hours that
the new worktree is untrusted; or having to prefix a bunch of
commands with `mise exec â¦` is annoying as well. A global alias for
all shells would be nice.
tempusfrangit wrote 21 hours 5 min ago:
I just added a post-checkout hook for my team:
`mise trust`
Resolves that trust issue right away and is scoped to your repo
(not global). We also have a make setup that helps the folks still
doing make things get all setup and trusted on the main work tree.
At a past job we had a local `doctor` script that did this.
NamlchakKhandro wrote 23 hours 35 min ago:
Use work trunk then
ricardobeat wrote 1 day ago:
What do you mean by that? If you have mise activate set up
correctly in your shell rc file, globally installed tools are
available in every shell. Thereâs also shim mode [1].
I use Claude on a mise-powered project daily without any issues
HTML [1]: https://mise.jdx.dev/dev-tools/shims.html
port11 wrote 1 day ago:
Not an expert, but Claude doesnât seem to be running with my
ZSH profile? Really, anything that isnât a terminal and tries
to use global commands, such as utilities that expect Node to be
available and so on. I always have to prefix commands, unless
using the terminal myself.
tempusfrangit wrote 21 hours 3 min ago:
You can also tell Claude to either run everything mise x or
refresh its shell and it will do the zsh re-exec and that
reloads the mise shims consistently.
These days also trivial to restart Claude ;)
PufPufPuf wrote 1 day ago:
Mise has two ways of running tools: the default one is ad-hoc
PATH modifications, but there's also a shim folder you can add
to PATH globally. If you mean the Claude desktop app or IDE
plugin, the shim option is usually required, just edit the PATH
the app is using (or the system-wide one).
paradox460 wrote 1 day ago:
Mise actually does support a primitive dependency system, you can
specify package deps in your config, so, for example, you can ensure
erlangs are installed before elixirs (bad example, elixir is already
internally dependent on erlangs, but you get the idea)
HTML [1]: https://mise.jdx.dev/dev-tools/#tool-dependencies
hk1337 wrote 1 day ago:
I really like mise but I donât think itâs an adequate homebrew
replacement. I use it more for project management dependencies and
tasks.
tempusfrangit wrote 21 hours 2 min ago:
100% agree. They are complimentary. Brew handles specific things
far better and mise handle polygot and some things where many
versions need to been handled on the same system.
But my list of brew items keeps getting shorter.
zchrykng wrote 2 days ago:
I like mise a lot, but only use it for project specific tool
management, JDK versions, etc.
I tried to use it for system wide things, but found it didn't work as
well for me with things that I wanted to just be tools where I didn't
care what specific version it was as long as it was more or less
current, Helix, NeoVim, RipGrep, etc.
NamlchakKhandro wrote 23 hours 39 min ago:
I use it for everything I can. Works very well
PufPufPuf wrote 1 day ago:
For system-wide things I usually use "latest" but it's nice being
able to downgrade and/or stick to a working version using
lockfiles. I remember back when I used Homebrew, Teleport shipped a
bug that prevented me from accessing our servers and downgrading
was a pain.
jeremyjh wrote 1 day ago:
mise use -g ripgrep@latest
I recently found mise and have become a fan as well. I have used
asdf for about a decade and it supports the same .tool-versions
files so initially I used it for those exact same things.
But I use four different computers for development regularly and
sometimes use Codespaces as well. While syncing dotfiles handles
most of my setup, it doesn't handle binary dependencies of my
dotfiles - my neovim setup wants fd & rg etc. So now those go in
the mise global config. I also have a global node & python along
with uv@latest which pretty much covers every tool I might want to
install.
I have never cared for the fact that homebrew tries to maintain
shared dependencies and several upgrades have broken stuff for me.
jpeeler wrote 2 days ago:
Mise does seem to be in a class of its own. As mentioned elsewhere,
it does rely on other registries such as aqua and obviously asdf. For
people who want to use Mise for brew packages, there's [1] .
HTML [1]: https://github.com/kennyg/mise-zerobrew
altern8 wrote 2 days ago:
That's kind of weird that you're using this announcement to steer
people to another project.
Or am I missing something..?
NamlchakKhandro wrote 23 hours 40 min ago:
Yeah that brew is terrible
PufPufPuf wrote 1 day ago:
We're discussing Homebrew now, which includes discussing
alternatives, and I'm telling my story of switching to a tool that
I found better for my purposes. I'm not affiliated or anything. I
agree this comment would be weird e.g. on the official Homebrew
blog.
hudon wrote 1 day ago:
I agree, but HN doesn't like metacomments that just complain on how
an article/comment is being upvoted, hence you being downvoted. See
guidelines: [1] Just downvote and move on.
HTML [1]: https://news.ycombinator.com/newsguidelines.html
altern8 wrote 1 day ago:
I see. OK, I'll do that next time, thanks.
chuckadams wrote 2 days ago:
As a PHP developer, I found mise's support to be pretty sub-par
compared to Shivam Mathur's packaging work for homebrew. Most of my
projects are using Docker anyway, the local PHP is for stuff like
static analysis that doesn't need it. And I've got a couple using
Nix, which laughs at everything else (but damn, the overall UX is
still even more hostile than git).
NamlchakKhandro wrote 23 hours 36 min ago:
Yeah... But pho. So no one really cares
Trung0246 wrote 1 day ago:
Yeah same issue with haskell. Apparently not many languages are
supported by mise.
notpushkin wrote 2 days ago:
Hmm, `mise use -g docker-cli` works for me. `docker compose` is a bit
trickier â it gets installed as `docker-cli-plugin-docker-compose`,
but docker-cli doesnât seem to pick it up. Iâve added a symlink
as `docker-compose` for the time being.
Also using brew for casks, and I think thereâs a couple tools I
couldnât install with mise (e.g. pngpaste and zbar for scanning QR
codes from screenshots).
FireInsight wrote 1 day ago:
There's the rename-exe option in mise.toml to rename the docker
compose binary to `docker-compose`. I've used it on some machine, I
think. Look it up in the docs, it doesn't take long to wire up.
notpushkin wrote 11 hours 9 min ago:
Yep, Iâve ended up doing exactly that: [1] The default
docker-compose definition comes from aqua:docker/compose though,
which does not support rename_exe. You have to specify
github:docker/compose instead.
HTML [1]: https://news.ycombinator.com/item?id=48501953
jdxcode wrote 8 hours 41 min ago:
doesn't aqua:docker/compose just work? it does for me
notpushkin wrote 5 hours 47 min ago:
Nope :-( Just tried it again, it installs and is available in
PATH as `docker-cli-plugin-docker-compose`, but `docker
compose` says âunknown commandâ. For docker-cli to pick
it up, it should be in
$DOCKER_CONFIG/cli-plugins/docker-compose (~/.docker by
default, though I use ~/.config/docker).
rename_exe doesnât do anything on the aqua backend either
(and isnât a documented option). Iâm on mise 2026.5.10
right now though so if you fixed something recently I might
be missing out!
PufPufPuf wrote 2 days ago:
FWIW you can replace pngpaste with a simple script: [1] Zbar seems
to provide prebuilt binaries here [2] (haven't checked it myself)
Thanks for the docker tip!
HTML [1]: https://til.simonwillison.net/macos/impaste
HTML [2]: https://linuxtv.org/downloads/zbar/binaries/
notpushkin wrote 1 day ago:
> FWIW you can replace pngpaste with a simple script
Neat! Got curious if you can do that without a temp file, turns
out you can:
#!/usr/bin/osascript -l JavaScript
ObjC.import("AppKit");
$.NSFileHandle.fileHandleWithStandardOutput.writeData(
$.NSPasteboard.generalPasteboard.dataForType("public.png"),
);
---
Edit:
> `docker compose` is a bit trickier
Iâve tweaked my setup a bit. This installs it as
`docker-compose` without symlinking required:
"github:docker/compose" = { version = "latest", rename_exe =
"docker-compose" }
And also you can manually symlink it to the Docker plugins dir so
`docker compose` works as well:
DOCKER_CONFIG="${DOCKER_CONFIG:-$HOME/.docker}"
mkdir -p "${DOCKER_CONFIG}/cli-plugins"
ln -s "$(mise which docker-compose)"
"${DOCKER_CONFIG}/cli-plugins/docker-compose"
thatxliner wrote 2 days ago:
Glad you're having a good experience, but I personally switched from
Mise back to Brew. I don't know if it was just my skill issue, but
there were too many packages which found Mise to be problematic.
PufPufPuf wrote 2 days ago:
Haven't had any serious problems so far!
thatxliner wrote 1 day ago:
When did you start using Mise? Maybe it's because I was a sort of
early adopter.
PufPufPuf wrote 1 day ago:
I've been using it lightly as a "better nvm" for a longer time,
but only switched to it as a primary "tool installer" a few
months ago. I've seen it improve quite a lot over the time, you
could give it another try!
nesarkvechnep wrote 2 days ago:
I did the same but with Nix.
dominotw wrote 2 days ago:
me too but feels like bringing bazooka to a watergun fight. might
go back to brew
dnlzro wrote 2 days ago:
Me too, but it definitely doesn't qualify as "zero glue code."
jdxcode wrote 2 days ago:
mise kind of supports dependencies, just not in the way people expect
coming from any other package manager. The dependencies in mise are
not automatic and all of them need to be manually defined. They're to
get around ordering issues since mise installs in parallel, e.g.: if
you use "pipx:black" you need to wait for python to finish
installing. (This is the "depends" option on tools")
This is intentional as mise is not intended to be a full
bootstrapping solution in the way homebrew/nix is, mise is designed
to be an overlay on top of existing systems. So if you want to manage
python with brew and black with mise it basically just works without
extra configuration. I think this design decision has paid off in
spades. It sounds like a drawback but at the end of the day it's
probably the #1 reason users find mise easy to use.
tempusfrangit wrote 21 hours 8 min ago:
I am a huge advocate of mise and all the en suite.
Two jobs in a row Iâve migrated most of our workflows to using
mise. Thanks for the amazing work (and I finally get to sponsor the
project!)
Mise and Brew are a powerful pairing.
PufPufPuf wrote 2 days ago:
Thank you for making Mise!
threecheese wrote 2 days ago:
Do you have an example? Sounds interesting.
PufPufPuf wrote 2 days ago:
Here's my modest collection of global tools I install in my
dotfiles: [1] Projects then have their own dependencies, e.g. [2]
Mise also has a task runner which automatically uses correct tools.
Onboarding a new team member is super easy now, they just need
Mise, "mise install" and they're up.
HTML [1]: https://github.com/JanPokorny/dotfiles/blob/master/dot_con...
HTML [2]: https://github.com/i-am-bee/agentstack/blob/main/mise.toml
srcrip wrote 1 day ago:
How does this even work? How does mise know how to install these
things?
c-hendricks wrote 1 day ago:
Mise has many backends. A lot comes from Aqua / asdf, but
there's others like GitHub, npm, cargo, http, etc.
It's all fairly well documented here:
HTML [1]: https://mise.jdx.dev/dev-tools/backends/
jrop wrote 2 days ago:
I really prefer to lock the version numbers instead:
mise use -g somepackage --pin
I can commit/rollback to known good versions. To upgrade:
mise up -il
Not so long ago, I was outspoken against mise. I've since come
around. It truly is a fantastic tool.
PufPufPuf wrote 1 day ago:
Mise now has lockfiles as a stable feature, which has the
benefit of hash checking if you use Mise in a CI environment!
stouset wrote 1 day ago:
What were your criticisms, and what changed?
mmcclure wrote 2 days ago:
I've been using mise as a pure version manager for a pretty long
time, and I had no idea you could use it for general tools like
this.
snthpy wrote 2 days ago:
Same
esafak wrote 2 days ago:
Don't forget that mise depends on package registries, to install
itself as well as its tools.
PufPufPuf wrote 2 days ago:
Mise installs itself as a static binary actually (but it's of
course packaged in many registries), and while there are some third
party registries it delegates to for some packages (aqua, asfd),
most stuff I have installed is either built-in, or from PyPI, npm
or GitHub, i.e. directly published by the upstream maintainers.
More info:
HTML [1]: https://mise.jdx.dev/dev-tools/backends/
esafak wrote 2 days ago:
You'll see that mise recommends installing itself exclusively
through package registries: [1] pypi, npm, and even github
(through releases) are registries.
curl | sh is an anti-pattern. It passes no security check.
HTML [1]: https://mise.jdx.dev/installing-mise.html
lachieh wrote 1 day ago:
There's always the chicken/egg problem of which dependency
manager to install first, though. AFAIK there's no "trusted"
installed for Homebrew on macOS though I might be wrong.
PufPufPuf wrote 2 days ago:
Exclusively? No, the very first option is the install script,
which downloads and unpacks the correct binary for your OS from
the Mise website:
curl [1] | sh
...which is the same way Homebrew is installed too.
HTML [1]: https://mise.run
0xbadcafebee wrote 2 days ago:
Personally I stopped using Homebrew after I got screwed too many times
on mandatory upgrades that I couldn't pin. I use a combination of Mise
and MacPorts now so I don't get any more surprise breakage and forced
obsolescence. Plus Mise allows me to upgrade to any new version,
whereas with Homebrew you have to wait for whenever the tap feels like
upgrading (llama.cpp tap skips every 10 releases)
bmurphy1976 wrote 2 days ago:
I was going to ask about others having this experience. I've been
using MacPorts for a couple years to install developer tooling
because it's far more consistent and doesn't surprise me with new
major versions of Python at random. I only use Homebrew for
application installation (i.e. Firefox, Slack, Spotify, etc.) that
are not available in MacPorts.
Of course, I've also made a concerted effort over the years to
migrate everything to uv for Python, pnpm for nodejs, etc. so maybe
it's not an issue for me anymore?
frollogaston wrote 2 days ago:
I switched to MacPorts because of permission issues with brew, used
it for years, then switched back after MacPorts inexplicably started
wanting to install like 9000 packages just to install something
small-ish like wget. Which is probably just as likely to happen with
any other package manager but whatever.
ryandrake wrote 2 days ago:
I've moved over to MacPorts due to Homebrew's aggressive support
phase-out schedule[1]. My daily driver iMac is now in the Tier-3 "go
away" bucket. Absolutely loved Homebrew for the short period of time
I could use it, but I'm not going to get on the hardware update
treadmill just to keep using it.
1:
HTML [1]: https://docs.brew.sh/Support-Tiers
bbkane wrote 9 hours 6 min ago:
I think you should blame Apple rather than Homebrew for this.
Apple, please support your hardware longer!
mikemcquaid wrote 2 days ago:
Glad you've found a workflow that works for you, genuinely.
For others still using Homebrew: a lot of work has gone into
upgrading only when we absolutely have to and showing these upgrades
to the user before we do them, including in this release.
pjm331 wrote 2 days ago:
and i `brew update && brew upgrade --greedy` every morning with my
first cup of coffee because i like to live on the edge like that
thanks for all your work!
PufPufPuf wrote 2 days ago:
I'm in the "switched most to Mise" stage, might look into MacPorts
for the remaining stuff, thanks for the tip!
bigyabai wrote 2 days ago:
Nix is also worth checking out, even if the Darwin packaging is a bit
flaky. I really appreciate having cross-platform devshells when I
have to alternate between Mac and Linux on a regular basis.
PufPufPuf wrote 2 days ago:
Mise is also cross-platform, we actually use it at work for
projects we develop locally on macOS, then build in CI on Linux --
it even supports multiplatform lockfiles. I had a few tries with
Nix but it's a lot to wrap your head around, Mise is simple to
"just try".
vhanda wrote 2 days ago:
Nix has a high learning curve. I now use Devbox [0] as it hides
all the complexity of Nix while still giving all the benefits.
Now I install far more packages via devbox (or devbox global)
than I do via HomeBrew (on osx) or pacman (on arch).
[0] -
HTML [1]: https://www.jetify.com/devbox
reactordev wrote 2 days ago:
Hell yeah, tap trust!!!
broxit wrote 2 days ago:
Thanks for the update. Is there any chance we can get some kind of
cooldown mechanism in Homebrew?
The only people I want to trust to quickly ship new code to my machine
are Apple and my browser (which handles more untrusted input than
anything else).
For everything else (vscode and its extensions, npm, homebrew, and all
the apps that self-update), I prefer to err on the side of waiting a
few days.
Some exceptional 0days might warrant a cooldown bypass, but even in its
current form users are vulnerable to 0days until they run brew upgrade.
gwerbin wrote 2 days ago:
It's all rolling release, but Homebrew maintainers have to bump the
version, not the software author (unless they put in a PR to Homebrew
core or publish their own Tap). What does Arch do here?
kstrauser wrote 2 days ago:
Thatâs not quite true. A recipe can specify a URL to check for a
new version, and the homebrew automation will periodically check
it. If thereâs a new version, it automates the version bump.
I used that for a package my company publishes, and neither we nor
any other human AFAIK ever manually update it in homebrew, yet the
newest version is always installable there.
b33j0r wrote 2 days ago:
Most handle this by having release channels. You would `brew
set-channel stable/edge`.
It annoyed me this week because I only had a few minutes to try
elixir 1.20 after the announcement, and brew lagged behind. You can
install erl and elixir by other means (I prefer to run my own
toolchains) but it wasnât worth doing in that moment.
Brew has or used to have a source option for some recipes and that
basicallllly solves it too, if you squint.
mikemcquaid wrote 2 days ago:
[1] details how weâre handling cooldowns and why we have a very
different risk profile to e.g. NPM.
Also, where we package things from NPM/PyPi/RubyGems that have been
subject to these attacks: we already apply cooldowns for you both
when packaging and when creating PRs to update to new versions.
HTML [1]: https://docs.brew.sh/Supply-Chain-Security
broxit wrote 2 days ago:
Glad to see that Homebrew is taking security seriously. Still, I
want to minimize the number of parties who can quickly get new code
onto my machine.
Your doc says "Human review of each release." What does that
actually entail?
uv had a release at 10:21am yesterday with 7,060 additions and
2,409 deletions. The new release was available in homebrew at
11:46am. What human review happened there?
I don't know of any other OS package manager that ships code this
quickly to users. Arch Linux has not pushed the new release of uv
yet, for example.
mikemcquaid wrote 2 days ago:
Our automation or a human submitted a PR, it was built and tested
in our sandboxed ephemeral CI environments, a human Homebrew
maintainer reviewed the CI results and PR diff and approved it
for merge which happened automatically if so.
If the ask is "who reviewed the diff": yes, a human didn't do
that. That's not actually happening for all packages in any
meaningful large ecosystem. I'm still unconvinced a cooldown
solves that until e.g. we have an open source security scanner
that runs on all Homebrew packages and requires a cooldown. Even
in that case, my suggestion would be that we just run it in our
own CI and block package release.
broxit wrote 2 days ago:
> Even in that case, my suggestion would be that we just run it
in our own CI and block package release.
I agree.
> open source security scanner that runs on all Homebrew
packages and requires a cooldown.
I think that is where all this is going in the longterm.
Until then, any upstream shenanigans are more likely to surface
in hours 0-48 after a new release than hours 0-4.
drewda wrote 2 days ago:
That doc is very useful and confidence inspiring in terms of being
mainly about people and process, rather than about one single
technical solution.
Relevant parts for those who have cool-downs at the top of mind:
> Across Homebrewâs history far more users have been protected by
shipping zero-day fixes quickly than have been exposed to npm-style
token-theft or crypto-mining attacks, so a global cooldown would be
a net negative for most usersâ security. The deeper reason
Homebrew does not need a general cooldown is that, unlike language
package managers, it already separates publishing from
distribution: an upstream release does not reach users until it has
passed human review, CI and checksum verification, which is the
very review window that language-ecosystem cooldowns are trying to
recreate.
[...]
> For ecosystems with a track record of fast-moving supply-side
attacks, Homebrew applies a download cooldown: a freshly-published
upstream version is not adopted immediately, giving the wider
community time to detect and report a malicious release before
Homebrew users are exposed. Cooldowns have been added for:
Bundler
RubyGems livecheck
npm and pip defaults
PyPI resource resolution
npm and PyPI in bump
alwillis wrote 1 day ago:
Just a FYI: Bundler now supports cooldown [1]: "Cool down before
you install: give new gems a few days to be vetted" -
HTML [1]: https://blog.rubygems.org/2026/06/03/cooldown-let-new-ge...
briandoll wrote 2 days ago:
It's in this release, see this section:
> Cooldowns, livecheck and bumping
PufPufPuf wrote 2 days ago:
That's only for upstream packages, i.e. what the CI pulls in when
building bottles. Homebrew itself is a rolling package manager,
essentially only supporting the "latest" version for each package,
which doesn't work well with the usual "only install packages older
than X" concept.
cryo32 wrote 2 days ago:
100% need this.
runjake wrote 2 days ago:
+1
For those who don't know what broxit is talking about, they're
referring to something like --minimum-release-age/minimumReleaseAge
in many pieces of software and package managers to reduce
vulnerability to supply chain attacks. Often times, such attacks are
detected within a few days of compromise.
Here's Bun's, as an example:
HTML [1]: https://bun.com/docs/pm/cli/install#minimum-release-age
joshuat wrote 2 days ago:
Is the eventual goal to move most formula/cask behavior into
declarative install steps and treat Ruby as an escape hatch?
mikemcquaid wrote 2 days ago:
Yes, exactly. The goal is you can install all official packages
without needing custom postinstall/preflight/postflight blocks.
ansonhoyt wrote 2 days ago:
Is there a way to `brew trust` inside my Brewfile? That'd be nice for
the handful of formulas I install from github repos via `brew bundle
--global`.
usrme wrote 2 days ago:
This is described here ( [1] ) if you scroll down a bit.
HTML [1]: https://docs.brew.sh/Tap-Trust
dpassen1 wrote 2 days ago:
`brew tap/recipe, trusted: true`
7839284023 wrote 2 days ago:
Awesome! Thank you for the update.
I noticed that homebrew updated _all_ my casks when running 'brew
upgrade' (even those with "auto_updates: true" in their Cask JSON API).
Is this intended, new default behavior?
This did not use to happen...
pdntspa wrote 2 days ago:
This sort of overly eager upgrading has caused me a lot of problems
over the years. I really wish it didn't default to updating the
entire world just because you want to update one package.
mikemcquaid wrote 2 days ago:
Yes this is intended. We skip those that seem to have already
auto-updated underneath. Our code for this is not yet rock solid so
please file issues for those you notice are not doing the right thing
here.
perryprog wrote 2 days ago:
You need to set HOMEBREW_NO_UPGRADE_AUTO_UPDATES_CASKS to 1, as
alluded to by a hint when it (first?) occurs. This means if you have
hints off (via HOMEBREW_NO_ENV_HINTS) then I suspect you can start
getting this behavior without warning which is a bummer.
See also:
HTML [1]: https://docs.brew.sh/FAQ#why-arent-some-apps-included-during...
hk__2 wrote 2 days ago:
> This means if you have hints off (via HOMEBREW_NO_ENV_HINTS) then
I suspect you can start getting this behavior without warning which
is a bummer.
I read this as "This means if you close your eyes you donât see
things, which is a bummer."
reaperducer wrote 2 days ago:
This means if you have hints off (via HOMEBREW_NO_ENV_HINTS) then I
suspect you can start getting this behavior without warning which
is a bummer.
When you instruct the system not to tell you things, the system not
telling you those things is a bummer?
If I could get more of the tech I interact with to stop doing
things I didn't ask it to, it would reduce a lot of stress and
wasted time.
perryprog wrote 2 days ago:
Ah, I suppose I did word that poorlyâI more mean that a
significant breaking change (Casks that previously were
documented as being excluded from auto-updating suddenly being
auto-updated) which can occur silently is a rough end-user
experience, even if the user explicitly opted into hiding hints.
DIR <- back to front page