Speed was my biggest complaint about brew, so I'm glad to cross that one off my list of things I don't like about brew.
Thank you for your hard work BTW, brew's been a lifesaver on macOS and immutable distros.
For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.
If it works in Homebrew, I almost always pick Homebrew. :) I have a pretty good feeling for what works since for the past few years I've mostly used an atomic distro (Aurora, based on Universal Blue, based on Fedora). It just comes naturally for me on Fedora too.
I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.
Then again I use versioned AppDirs on Linux since +20 years anyway, so I am not really into any arbitrary disctinction random linux distributions try to push down onto the (downstream) userbase. Besides, if you compile from source, why would you want to rely on the distribution package manager to begin with?
None of them allow for versioned AppDirs by default as far as I know; NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course), but as far as I know if you are on e. g. a debian system, you can not use it for a versioned AppDir layout.
Distinction: https://news.ycombinator.com/item?id=49683258
I use "dnf" to upgrade my system and "flatpak update" and "brew upgrade" to upgrade the apps I've installed.
An app like VirtualBox does not install using Flatpak or Homebrew, so I would use dnf for that. It's usually an app or two that doesn't work via Flatpak/Homebrew/AppImage that I need to install using dnf.
Also Guix, which is inspired by Nix. Don’t know about AppDir support, though. Are AppDirs more of a general concept or a formalised standard? In what capacity are you using them?
I would think this is one of the most critical dependency that you would not want to get right away at let it rest for a couple of days
Our model is very different to those where cooldowns exist and make sense. As-is if would just delay security updates too.
https://github.com/MikeMcQuaid/AgentIDE
I actually wrote my own “Agent IDE” to make this prompt/review/push flow easier.
The lessons learned were instead used to make the Ruby frontend much faster.
Fish 4.0: The Fish of Theseus (fishshell.com)
906 points by jdxcode on Dec 28, 2024 | hide | past | favorite | 198 comments
https://github.com/Homebrew/brew/issues/7755#issuecomment-51...
The only problem some things still have a dependency on requiring python and others on the system. The problem being that they’re there, mise works just fine.
Eg: mise use -g gcloud instead of brew install xxx
It can even do that for npm packages! Like mise use -g npm:xxx
Were using Bubblewrap on Linux and moved to Landlock this release.
P.S. HUGE fan of your blog and writing Simon, keep up the great work. It’s the #1 resource I recommend to anyone in the industry wanting to learn more about LLMs (and pelicans).
I’ll update Xcode, but I will definitely not install macOS 27.0
Is it Claude or Codex built?
alias u="brew update && brew upgrade --greedy -y && brew upgrade --cask -y && brew cleanup"The supply chain security policy of brew is basically non existent and optimized for low-friction contributions. Think wikipedia. No enforced commit signing, review signing, or multi-party release signing, and thus everything is honor system.
Do not put brew anywhere near systems that access production or even on systems used to review production-bound code.
We take supply chain security very seriously, moreso than many package managers.
That really put me off.
It's so annoying how deeply UNIX packaging philosophy assumes that installation directories are something you hard-code at build time.
It makes me think of when Arch merged /usr/bin and sbin with /bin and sbin. Having them split made sense in a ton of scenarios that used to be very common, but increasingly the split was vestigial for most users.
But these days, "early boot" is handled by initramfs and we've all got drives large enough to not need the split anyway.
Postgres is an example of this: the various directories are set at build time.
All that said, when you are running without a sandbox installing to a nonstandard location, not everything works consistently. I run this mode all the time. But it has been getting better.
It uses root once to chown its prefix directory /home/linuxbrew/.linuxbrew
- 2019 Intel iMac user.
From the release notes:
> The Intel support decision reflects the limits of a volunteer-run project: Apple have dropped Intel x86_64 support from macOS 27 Golden Gate and GitHub Actions will retire Intel macOS runners in autumn 2027. If Apple and Microsoft’s GitHub, two of the world’s largest technology companies, cannot continue supporting macOS Intel x86_64, sadly neither can Homebrew. MacPorts still supports macOS Intel x86_64 and is likely to provide better results on this platform.
Linux already has world class package managers.
Supporting macOS Intel has been significantly harder, slower and more expensive for us the last few years than adding ARM Linux support. If it was easy and free we’d have kept it for longer (until Apple and GitHub killed theirs at least which is coming in less than a year).
it can be installed with:
brew install homebrew-app
We hope to allow all prefixes under 64 bytes in future.
I'm back to the old installation methods !
Apart from the issue of having to compile the downloaded software leading to spinning fans, I'm not too concerned.
If you want to continue using the same MacBook that will be only path forward when Apple decides to EOL it (if it hasn't already happened).
I'm a long time Homebrew on Linux user, it works really well. I always prefer it over the distro supplied package manager for user facing CLI apps.
I'm not blaming the Homebrew project/developers here, but the fact that many people are okay with deprecating perfectly fine hardware.
I am already looking at Linux, but still need to get out of the Apple ecosystem. I am not going to spend +2500 Euros every 5 years on a laptop
The actual front page has "The Package Manager for Everywhere" as its subtitle (and that exact description as part of its <title>), and that is basically all you need to know. It's a staple for Unix-y power users on macOS (but supports Linux too, including WSL), and version 1.0 will be ten years old next week. You're not very far off from complaining that Postgres release notes don't explain that Postgres is a database.
The second header on the main page:
What Does Homebrew Do?
Homebrew installs the command-line tools and applications you need across macOS, Linux and WSL.
Homebrew is the Mac equivalent of APT, Pacman, RPM, BSD ports, etc. It's a fairly traditional package manager for software that doesn't come with macOS. "brew install postgresql" installs Postgres into /opt/homebrew, for example.