Earlier quoted context omitted.
Do you have an example? Sounds interesting.
Here's my modest collection of global tools I install in my dotfiles: https://github.com/JanPokorny/dotfiles/blob/master/dot_confi... Projects then have their own dependencies, e.g. https://github.com/i-am-bee/agentstack/blob/main/mise.toml 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.
Show HN: Homebrew 6.0.0
221–230 of 380 posts
Re: Show HN: Homebrew 6.0.0
#222Earlier quoted context omitted.
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 outd…
> 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.
Mixing user and system software is like having Photoshop and all of your games install their files directly into the Windows directory.
Re: Show HN: Homebrew 6.0.0
#223Re: Show HN: Homebrew 6.0.0
#224Earlier quoted context omitted.
https://docs.brew.sh/Supply-Chain-Security 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.
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 ne…
[1]: "Cool down before you install: give new gems a few days to be vetted" - https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-b...
Re: Show HN: Homebrew 6.0.0
#225Re: Show HN: Homebrew 6.0.0
#226I 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.
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…
Re: Show HN: Homebrew 6.0.0
#227Top three things I install first are Sublime Text, Homebrew, and modern Bash (I'm not switching to Zshell). Great tools make computing enjoyable.
Re: Show HN: Homebrew 6.0.0
#228Homebrew 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.
Absolutely!
Re: Show HN: Homebrew 6.0.0
#229Earlier quoted context omitted.
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?
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?
Re: Show HN: Homebrew 6.0.0
#230I have switched my full OS-level dev env to https://mise.jdx.dev/ 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 dy…