| 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. |
| |
| ▲ | Wowfunhappy 2 days ago | parent | next [-] | | 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! | | |
| ▲ | Nab443 2 days ago | parent [-] | | 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. | | |
| ▲ | int_19h a day ago | parent | next [-] | | 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. | |
| ▲ | Wowfunhappy 2 days ago | parent | prev [-] | | 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. |
|
| |
| ▲ | thewebguyd 2 days ago | parent | prev | next [-] | | > 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? | | |
| ▲ | ryandrake 2 days ago | parent | next [-] | | 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. | | |
| ▲ | ChocolateGod 2 days ago | parent [-] | | Mac apps outside the app store can still be sandboxed, but they have to be signed. |
| |
| ▲ | shadowgovt 2 days ago | parent | prev [-] | | "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. | | |
| ▲ | ryandrake 2 days ago | parent [-] | | 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! | | |
| ▲ | int_19h a day ago | parent [-] | | 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. |
|
|
| |
| ▲ | CharlesW 2 days ago | parent | prev [-] | | > …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 | | |
| ▲ | ryandrake 2 days ago | parent [-] | | Wow, they even have a .pkg installer. Had no idea. Is this new? | | |
| ▲ | CharlesW 2 days ago | parent [-] | | 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/ |
|
|
|
| |
| ▲ | xmodem 2 days ago | parent | next [-] | | I've been using MacPorts since before homebrew existed and never switched away. | |
| ▲ | fouc 2 days ago | parent | prev | next [-] | | 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. | | |
| ▲ | antihero 2 days ago | parent [-] | | If you're depending on specific versions, don't use a general system package manager, use something like mise or asdf. |
| |
| ▲ | CharlesW 2 days ago | parent | prev | next [-] | | 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/ | |
| ▲ | ryao 2 days ago | parent | prev | next [-] | | I am a fan of Gentoo Prefix. Others like pkgsrc. | | |
| ▲ | fouc a day ago | parent [-] | | I've heard of some people using pkgsrc as their package manager in macOS. First time I heard about Gentoo Prefix. neat! |
| |
| ▲ | chme 2 days ago | parent | prev | next [-] | | nix possible with lix, if you can stomach nix syntax. | | |
| ▲ | fouc a day ago | parent [-] | | 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. |
| |
| ▲ | snickerdoodle12 2 days ago | parent | prev [-] | | apt and yum/dnf are pretty great |
|
