This always floors me when I have to use a non-Linux computer. The difference between package management on Linux and other OSes is shocking. Dnf, Yum, Pacman are all so convenient and straightforward.
I can't understand why Windows and MacOS don't have anything official that fills this gap.
I prefer Brew to every Linux package manager I've used.
I like that it's totally separate from the base OS.
I like the insanely large package selection, including binary [edit: that is, closed-source binary] packages. I almost never install any tool that's not in Homebrew—usually I just blindly try it, and sure enough, I got the package name right and it does have it, and it installs no problem. Gentoo's Portage and Arch's whatever-they-call-it are pretty close, but those are... higher touch operating systems, to put it mildly (I was a heavy Gentoo user for a few years—I know Arch is less of a pain than that, but it's still got rolling-distro and various DIY rough edges)
I don't try to use it to install development dependencies like some people seem to. It's not good for that, but doing that on Linux isn't a great idea, either. Your project should manage its own deps separate from your development system, or you're gonna have a bad time sooner or later, unless you are only deploying to exactly the system config that you're developing on.
The main problem is that the majority of software in the Windows and Mac world doesn't come in a "package-manager" format, not really.
For *BSD and Linux, the package manager is great because if you can think of it, it's probably there ready to be installed; as long as it's software like TeX or emacs or vi or something else available in an open-source way.
But stand-alone programs? Not even things like Photoshop, I'm talking something written by someone and you want to install it? That's not as compatible with the Linux method, but Windows and Mac both have standard procedures and installers for them. Snap tries to do something here, but it's a complete joke.
And homebrew (and anything equivalent for WSL?) works pretty well.
I've not used macs for a few years, but has homebrew become a lot better then? Because my recollection of it is that it worked fine for small sets of well-maintained packages, but it's much, much slower than the linux package managers, and there were tons of compatibility issues once you even slightly left the beaten path. Also, I remember fighting with many apple CLI tools; they seemed to be wildly out of date with the comparable linux tooling, to the point that you sometimes needed to homebrew something technically already part of the base OS just to get other things working (e.g. IIRC bash)
Incidentally, on windows there are the beginnings of package managers nowadays, e.g. chocolatey. They're nothing like as good as those in linux, but better than nothing. Chocolatey's focus isn't quite the same as homebrew, however, so they're not strictly comparable.
It ... "works". For most things you may want, it works pretty well, but it's not at advanced as even Gentoo's portage, and once you leave the beaten path it can be all sorts of hell trying to figure out how exactly to compile something yourself.
However, I've experienced the same on Ubuntu and RedHat - if they don't have what you want in a repo already, and you can't find one providing it, trying to roll your own can cause all sorts of fun explosions.
Anything GPL included with MacOS is stuck at the GPL v2 - since many things like bash went to v3 they don't update anymore; one of the reasons MacOS changed to zsh as the default shell.
> But stand-alone programs? Not even things like Photoshop, I'm talking something written by someone and you want to install it? That's not as compatible with the Linux method
There's definitely some room for improvement here, but fwiw you can double-click executables on Linux to run them just like you would on Windows (or to an extent, MacOS). I think the "solution" here is not to rely on portable software, and when you do need to rely on it, use a packaging format like AppImage.
> And homebrew (and anything equivalent for WSL?) works pretty well.
I hate to burst your bubble, but Homebrew is genuinely awful. The vast majority of Mac devops issues I've encountered stem from a Homebrew issue, as a matter of fact. Oh no! Software (x) isn't running on Mike's M1, but it runs just fine on Melissa's x86 machine! The problem? Homebrew installs software to different locations depending on your system architecture. That's right, the same package will end up in different places when the only difference between machines is CPU architecture. That's just one issue, I have gripes about reinstalling, leftover files, formulae syntax, Linux "compatibility", UX and more... the author isn't wrong when they say the experience simply doesn't compare to apt or pacman.
Yeah, homebrew isn't the greatest by any means, but it seems to have more stuff and more people use it than fink or macports anymore, so usually there's a workaround somewhere.
The MacOS "app bundle" is a really cute solution to the installation/library problem, and I wish something like it had caught on in the Linux world. It seems AppImage is heading this way.
App bundles are neat, but when given the option of "an app directory on top of a traditional Unix filesystem layout" or "everything is packages", I'll tend to choose the latter. It might just be an impasse situation; I think the ideas of package management are developed about as far as they can go, even newcomers like Flatpak can't really bring anything new to the table. The only package manager that's impressed me in recent years is Nix. I think if most developers decided to throw their weight behind Nix packages, we could live in the "it just works" utopia that Linux and Mac developers alike have been dreaming of for years.
The bane of package managers is when you have to go beyond what they supply for whatever reason - horrible memories of trying to upgrade php on old versions of CentOS still haunt me.
They do. On Windows it's msi, and Mac it's pkg. But, for whatever reason folks have preferred to build their own package solution instead of learning the OS native approach. I'm guessing because building your own makes for an easier end user CLI experience.
Microsoft made the mistake of adding non-deterministic behaviour to MSI files, because without that the package format is pretty much everything I'd want out of a software packaging system.
I think companies wanted to stuff branding and ads into their installers, so MSI files fell out of use. Modern Windows seems to prefer msix and other weird UWP-based formats, but I don't think you can just install those.
What Windows is missing though, is a clean way to manage these MSI files. A reinstall or an uninstall shouldn't take twenty windows and four different "next" buttons to process. When Microsoft created the Microsoft Store, they neglected to also add a command line option for installation (you can manually install a package, but you'll need to do updates yourself from what I can tell). Just add a Powershell command like "MSStore-Install" and the entire ecosystem would be so much nicer to use!
I suppose this is what they're trying to do with WinGet, after forking AppGet and leaving the original project to die. For some reason they like to reinvent the wheel every time someone thinks of a new way to install binaries onto a computer.
You can use Chocolatey until WinGet gets some traction. You have everything there and no more clicking around. I haven't started MSI by hand in last 5 years.
Errr ... because they're commercial operating systems, with the expectation that software is not just universally available for no cost?
The respective stores for macOS and Windows are changing this, but there's a 30-ish year history of needing to register and pay for your software, so having it all just _there_ still isn't really a thing.
Pretty much the only time I install something and it's not through Homebrew (unless it's a dependency of a project, which I manage separately, because I like having an easy life and I'd do the same on Linux, for the same reasons) is when it's some sub-100-stars GitHub project. And half the time, those are on there, too.
But Chocolatey exists too and is pretty nice. I have used both of them but I know Chocolatey a lot better. They both are basically used as wrappers for traditional package formats like msi or other commercial installers. I guess windows has msix and appx as well which are used in the Microsoft Store.
This always floors me when I have to use a non-Linux computer. The difference between package management on Linux and other OSes is shocking. Dnf, Yum, Pacman are all so convenient and straightforward.
I can't understand why Windows and MacOS don't have anything official that fills this gap.