Wow, I did not realise that you can use brew outside of Mac. Thanks.

I knew, but am surprised anyone actually uses it. Are there more of you?

I use it when working on Ubuntu/Debian LTS systems, since the Homebrew packages tend to be more significantly more up-to-date than whatever's packaged in the LTS Apt repositories.

As an added benefit, unlike apt, you don't need root to install (most) brew packages.

Have you tried https://mpr.makedeb.org/ ?

It seems like it’s made for Debian based systems, much like the AUR for Arch.

Absolutely use and love homebrew on linux. All of the fun rust-based tools that get posted here on hackernews (exa, fd, ripgrep, fzf, etc.) are all there and much more up to date than apt. Heck, I find brew is more up to date than nix in some cases.

I have been using it on an WSL/Ubuntu instance just over the last few days... for some things its pretty handy (e.g. in the context of k8s I get a more up to date version of the excellent kubectx utility via brew than apt). But for others its bit of a pain, e.g. building Python through pyenv and using OpenSSL in brew, etc.

always using brew on linux/osx, I wish they were supporting shipping binary /cask on Linux like on OSX (only recompiling)

I use it all of the time! It has a plethora of packages and they're often more up-to-date than the package manager of whatever distro I'm on (usually Debian or Amazon Linux 2).

It's been there for a while but it's done as an afterthought which can lead to cascading problems, and it isn't a great idea to use it. It stomps all over the distro's Python and is generally insecure, it's much safer to use the distro's own package managers.

I believe it came about to cater to Mac developers that don't want to bother with Linux based package managers, this becomes an easy out, but as mentioned previously, is more of an afterthought.

Is there a reason these aren't just in the native package managers? Licensing? It blows my mind I can't install a RHEL-alike and run `dnf install kubernetes` and just, like, have what I need. Sure, maybe I have to pick a container runtime, fine. This is even more astonishing when you realize Fedora CoreOS has no actual RPM for kubernetes even though it is ostensibly a container hosting OS. How do I let rpm-ostree run wild and keep kubernetes at a compatible version?

The installation steps for Kubernetes and the rest of the ecosystem like minikube and helm are all essentially `wget install.sh | sh`. What am I missing? How do people do this in production environments?

> Is there a reason these aren't just in the native package managers?

Some major Linux distros do ship with official k8s packages. For instance, Ubuntu even dedicates an article on how to deploy multiple k8s choices.

https://ubuntu.com/kubernetes/install

That only has options to install microk8s with snap.

Why not use your distribution's native package installer?

k8s ecosystem tools are fast changing and native package repos are woefully out of date. Minikube in particular has a habit of just straight up breaking and requires a lot of reading long github issues only to realize there's a fix in a version just pushed 24 hours ago.

> k8s ecosystem tools are fast changing and native package repos are woefully out of date. Minikube in particular has a habit of just straight up breaking and requires a lot of reading long github issues only to realize there's a fix in a version just pushed 24 hours ago.

I don't understand what point you tried to make. If what you want is a stable install to avoid breaking changes pushed in unstable releases, why not stick with a working install just like what you get with brew?

I don't see how using exotic non-standard package managers make releases more stable.

Brew doesn't give you a stable or repeatable install. You can't pin tools to specific versions, they'll get updated whenever you update brew. This is by design and kinda the core ethos of brew. The k8s tooling is generally all meant to have you using the bleeding edge stuff--every tool readme usually says get the latest build from a github release package, brew just effectively does that automatically.

Brew will, by default update everything it manages when you run it.

Depending on your perspective, this is either horrifying and annoying or the best thing since sliced bread.

Huh. I guess that makes sense? But can't the tools just host their own rpm and deb repos? I guess that's too much operational overhead? Seems like an operational nightmare to run this in prod without the os-level package managers. Are production environments rolling their own RPMs?

At this point it seems to be that making Kubernetes nearly impossible to self-host is a whole point. You either pay money to dedicated experts or pay money to clouds.