← Back to context

Comment by maxloh

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

32 comments

maxloh

Reply
Washuu  3 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.

mayama  3 days 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  3 days 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.

  • wolrah  3 days 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  3 days 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  3 days 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  3 days 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.

      1 reply →

  • curt15  3 days 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.

  • selicos  3 days 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.

vondur  3 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.

colordrops  3 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  3 days 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.