← Back to context

Comment by hk__2

3 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!

17 in September. Thanks for all your great work at the time! Hope you’re well <3

  • just updated to 6.0.0. already loving `brew trust <tap>` 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

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.

  • > 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.

  • 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.

  • > 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.

    • 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.

      4 replies →

    • 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.

    • 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.

      2 replies →

  • 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.

  • 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.

    • 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.