Do you use brew pkg manager on Linux?

No, we already have a package manager.

I am using an atomic distribution (uBlue) and installing packages with homebrew is much more convenient than overlaying them with rpm-ostree.

I'm using it on Ubuntu and Debian on WSL - I have a Windows 11 laptop at my job, but I do most of my work on linux, so I chose to use Ubuntu and Debian, but I needed some packages that are not up to date with the native package manager, so I went with brew and I can say it's very good!

and stupid people are downvoting me for what? because I told my use case? fucking idiots!
- Well a comment like this will not help in your case, calling people idiots is not nice. Most on Linux sub don't like Windows, you should expect this. No need to get furious about random internet points. I also don't like Windows, but wish you best luck with it. At least you are using Linux on it. Just ignore people who hate YOU for that.
- Because, WSL is not a proper way to use / run Linux.

I don't, but people probably do because the package(s) they want are more available in that system.

It's primarily for Macs, isn't it? Cross-platform availability is probably a factor.

Or just because they are used to it and don't want to learn a new package manager and all its features and quirks. Would be a shame though. Everyone should!

I will if it's an obscure package that has a recipe, otherwise I avoid it to keep my paths as clean as possible. It can end up making a confusing mess of things if you accidentally install something via other means that also gets installed by brew as a dependency, as an example.

No I use Debian. For anything that's somehow not packaged for it, there's Docker.

I still don't get Docker. Can we see it as a universal package format that works across all systems, kind of? Well in that regard, we also have JavaScript based applications for the web browser and Web Assembly to run locally too.
- It's more than a packaging format but yes. It includes all dependencies needed to run the main program in a container but the kernel. It's a complete separate root filesystem. When you run it, as intended, a single process is started which loads all the things it needs from that filesystem. It's isolated from the rest of the system unless you share resources with it, like directories or special devices. Obviously this results in larger packages but there is a clever way to save on that overhead with layering, so in practice while still significantly larger than single program deb files, it's not nearly as bad as it sounds. The thing is that Flatpak and Snap also package dependencies to a different degree.
- You can think of Docker and Podman as an almost zero overhead (CPU and RAM) way of running one distribution on another. So, you can run an application in Docker that expects to be running on a different distro from what you use (say Ubuntu Jenkins but actually running on Debian). The environment that the applications run in are called “containers”. Mostly they contain the filesystem layout and application libraries that the app expects.
  
  Docker itself is designed to sandbox the application away from your host system. A related technology, Distrobox, uses the same containers but in a way that the applications know they are running on your system with full access to your display manager and home directory.
  
  I run an Arch Distrobox on every distro that I use. This allows me full access to all the Arch repos and the AUR even on other distros ( eg. Alpine, Chinese Linux, or Debian).
  
  Flatpak also uses containers and so you can consider Distrobox as a Flatpak alternative. Flatpak containers are not the same as those that Docker uses but they rely on the same underlying Linux kernel features to do what they do. In Flatpak, you are essentially running the Freedesktop distro on top of your host distro (so much like Distrobox with the guest distro chosen for you).

I stick to stuff like Pacman and paru

I use nix for extra packages on my linux desktop. I don"t like brew at all.

whoever says pacman is enough either have all the time in the Universe to configure the miniscule knobs or have never done serious development with multi-platform/compiler deployments. controlling which compilers are used for which packages in pacman (or any other default package manager for that matter) is a headache. having multiple versions of non-conflicting gcc, llvm, cuda etc is priceless and very easy with brew.

elitism aside, brew is genuinely a good package manager when it comes to imperative ones. I still use it on my desktop arch extensively. ofc, if you have nix, there is really no good reason for it (and I'm not even sure it's possible).

PS. "but you can use docker" -- not if you want to have the same performance especially on GPUs. also have you ever tried containerizing HIP? it's a frigging nightmare.

PPS. if you disagree with the first paragraph -- please reach out or send links. i'd love to learn how to do these on finite timescales of our lifetime.

OF COURSE there has to be yet another package manager I didn't know about on top of the dozen other ones... 😑

I did a few times on bazzite. But it's now aurora. Haven't had anything I was missing. Was also exporting a few things from arch in distrobox. Was more of a experiment then a necessity.

I don't use brew but I do use Guix on top of PopOS, for most of the same reasons I use Guix System as a daily driver distro on my other machines. The PopOS install is meant to act as a "Windows replacement" so it has proprietary drivers, Steam, etc. For anything that's not a system package I get it from Guix if possible, because I prefer Guix's package management and its commitment to software freedom.

On Windows I use Scoop which has a handful of similarities in terms of user package management.