Hacker News Reader

Comment by fouc | Hacker News Reader

I first encountered `curl | bash` in the macOS world, most specifically with installing the worst package manager ever, homebrew, which first came out in 2009. Since then it's spread.

I call it the worst because it doesn't support installing specific versions of libraries, doesn't support downgrading, etc. It's basically hostile and forces you to constantly upgrade everything, which invariably leads to breaking a dependency and wasting time fixing that.

These days I mostly use devbox / nix at the global level and mise (asdf compatible) at the project level.

View on HN

Ironic, because macOS's package management system is supposed to be the simplest of all! Applications are supposed to just live in /Applications or ~/Applications, and you're supposed to be able to cleanly uninstall them by just deleting their single directory. Not all 3rd party developers seem to have gotten that memo, and you frequently see crappy and unnecessary "installers" in the macOS world.

There may be good or bad reasons why Homebrew can't use the standard /Applications pattern, but did they have to go with "curl | bash"?

> …did they have to go with "curl | bash"?

That's one of many options, documented at the first text link of the home page. https://docs.brew.sh/Installation

Wow, they even have a .pkg installer. Had no idea. Is this new?

Without going too far down the rabbit hole, it looks like the maintainers added it in 2023. In the process, I was reminded that the installer initially required Ruby! (/usr/bin/ruby -e "$(curl…)

FYI, mas is the equivalent of a package manager for macOS apps (a.k.a. a CLI for App Store). https://github.com/mas-cli/mas

Other than brew, I use mise for everything I can. https://mise.jdx.dev/

The Applications folder system does work really well for GUI apps! It's not really made for command line apps.

For command line apps, the equivalent would probably be statically-compiled binaries you can just drop somewhere in your PATH, e.g. /usr/local/bin/. For programs that are actually built this way (which I would personally call "the correct way") this works great!

I would not call apps built statically "the correct way". It offers benefits but also drawbacks. One of them being that you can't update statically linked libraries in it with security fixes without replacing the binary completely, which can be an issue if the context does not allow it (unsupported proprietary software, lost dependency code, ...). It can also lead to resource consumption faster, which can be an issue in resource constrained systems.

I know, I said that I would call it the correct way. :) I'm aware of the drawbacks, I just think they're clearly outweighed by the benefits.

If nothing else, consider that the limitations of a statically linked binary match those of a traditional Mac application bundle. While Mac apps are usually dynamically linked, they also include all of their dependencies within the app bundle. I suppose you could argue it's technically possible to open an app bundle and replace one of the dylibs, but this is clearly not an intended use case; if nothing else, you're going to break the code signature.

If the app is actively maintained, it will update the dependency to fix the security issue.

If the app is not actively maintained, unless trivial, it likely has unpatched vulnerabilities of its own anyway.

And on macOS, if the app is not actively maintained, it usually breaks after a couple major releases regardless of anything else, because Apple doesn't believe in backwards compatibility.

> Not all 3rd party developers seem to have gotten that memo

This frustrates me to no end on macOS. Not only do you see crappy installers like you said, but a ton of applications now aren't even self contained in ~/Applications like they should be.

Apps routinely shit all over ~/Library when they don't need to, and don't clean up after themselves so just deleting the bundle, while technically 'uninstalls' it, you still have stuff left over, and it can eat up disk space fast. Same crap that Windows installers do, where they'll gladly spread the app all over your file system and registry but the uninstaller doesn't actually keep track of what went where so it'll routinely miss stuff. At least Windows as a built-in disk clean up tool that can recognize some of this for you, macOS will just happily let apps abuse your file system until you have to go digging.

Package managers on Linux solved this problem many, many years ago and yet we've all collectively decided to just jump on the curl | bash train and toss the solution to the curb because...reasons?

Yep, same problem on Windows. It's almost always a mistake to give 3rd party developers unrestricted access to your filesystem, because they don't care and will shit their files all over it.

I wish more applications were distributed by the Mac App Store, because I believe App Store distributed apps are more strongly sandboxed and may not allow developers to abuse your system like this.

Mac apps outside the app store can still be sandboxed, but they have to be signed.

"Reasons" is "Nobody wants to wait for the package maintainers to decide that their favorite new shiny toy is enough a priority to update it to a version recent enough to match the online documentation for the new shiny toy," mostly.

As I mentioned somewhere side-thread: Debian Unstable is only three minor versions behind the version of Rust that the Rust team is publishing as their public release, but Debian Stable is three years old. For some projects, that dinosaur-times speed. If I want to run Debian Stable for everything except Rust, I'm curl-bashing it.

As a user, if you need to run recent versions of your tools, I'd argue Debian (at least Debian Stable) is not for you. Luckily we have many choices among Linux distributions!

There's nothing wrong with Debian for running recent versions of your dev tools; you just shouldn't expect to get them from the official Debian repositories. But there are third-party repositories for things like e.g. latest Node versions. I would expect there to be something for Rust, as well, but apparently they are also packaging rustup now.

Why is homebrew the worst? Do you have a recommendation for something better? I default to homebrew out of inertia but would love to learn more.

MacPorts is a good alternative, but you'll find that Homebrew is absolutely not the worst. Personally, I find brew fast and reliable. Look at mise (`brew install mise`) for managing any developer dependencies. https://mise.jdx.dev/

Lately I've been using devbox (nix wrapper) for my homebrew-like needs via "devbox global add <whatever>", for project specific setup I stick with mise (asdf-compatible)."

I don't like homebrew because I've been burnt multiple times because it often auto-updates when you least want it to and breaks project dependencies.

And there's no way to downgrade to a specific version. Real package managers typically support versioning.

If you're depending on specific versions, don't use a general system package manager, use something like mise or asdf.

nix possible with lix, if you can stomach nix syntax.

devbox is a nice wrapper for nix syntax. thanks for the tip about lix, it looks like I can use devbox+lix instead of the determinate nix installer.

apt and yum/dnf are pretty great

I am a fan of Gentoo Prefix. Others like pkgsrc.

I've heard of some people using pkgsrc as their package manager in macOS. First time I heard about Gentoo Prefix. neat!

I've been using MacPorts since before homebrew existed and never switched away.

Reply on news.ycombinator.com