4 ms·
Much of the reason `curl | bash` grew up in the Linux ecosystem is that "single binary that just runs" approach isn't really feasible (1) because the various di
by shadowgovt 1y ago
Much of the reason `curl | bash` grew up in the Linux ecosystem is that "single binary that just runs" approach isn't really feasible (1) because the various distros themselves don't adhere to enough of a standard to support it. Windows and MacOS, being mono-vendor, have a sufficiently standardized configuration that install tooling that just layers a new application into your existing ecosystem is relatively straightforward: they're not worrying about what audio subsystem you installed, or what side of the systemd turf war your distro landed on, or which of three (four? five?) popular desktop environments you installed, or whether your `/dev` directory is fully-populated. There's one answer for the equivalent of all those questions on Mac and Win so shoving some random binary in there Just Works.
Given the jungle that is the Linux ecosystem, that bash script is doing an awful lot of compatibility verification and alternatives selection to stand up the tool on your machine. And if what you mean is "I'd rather they hand me the binary blob and I just hook it up based on a manifest they also provided..." Most people do not want to do that level of configuration, not when there are two OS ecosystems out there that Just Work. They understandably want their Linux distro to Just Work too.
(1) feasible traditionally. Projects like snap and flatpak take a page from the success Docker has had and bundle the executable with its dependencies so it no longer has to worry about what special snowflake your "home" distro is, it's carrying all the audio / system / whatever dependencies it relies upon with it. Mostly. And at the cost of having all these redundant tech stacks resident on disk and in memory and only consolidateable if two packages are children of the same parent image.
- fouc 1y agoI 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.
- tghccxs 1y agoWhy 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.
- CharlesW 1y agoMacPorts 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/ https://mise.jdx.dev/
- fouc 1y agoLately 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 1y agoIf you're depending on specific versions, don't use a general system package manager, use something like mise or asdf.
- chme 1y agonix possible with lix, if you can stomach nix syntax.
- fouc 1y agodevbox 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 1y ago
- JoshTriplett 1y agoStatically link a binary with musl, and it'll work on the vast majority of systems. > they're not worrying about what audio subsystem you installed Some software solves this by autodetecting an appropriate backend, but also, if you use alsa, modern audio systems will intercept that automatically. > what side of the systemd turf war your distro landed on Most software shouldn't need to care, but to the extent it does, these days there's systemd and there's "too idiosyncratic to support and unlikely to be a customer". Every major distro picked the former. > or which of three (four? five?) popular desktop environments you installed Again, most software shouldn't care. And `curl|bash` doesn't make this any easier. > or whether your `/dev` directory is fully-populated You can generally assume the devices you need exist, unless you're loading custom modules, in which case it's the job of your modules to provide the requisite metadata so that this works automatically.