Hacker News Reader

Comment by mike256 | Hacker News Reader

You shouldn't do that. At least download the installer first, have a short look at it and decide if you like to run it.

I personally avoid software whose manual suggests this type of install because I think of the developers as not that intelligent ones.

View on HN

The content of the file being served can easily be switched based on the user agent accessing the file (curl vs a browser)

Instead, you shoud wget, review and execute locally or something similar.

Yeah, no, you shouldn't do that. Kinda my point in writing that, right? But it's terrifyingly commonplace and needs to stop.

I don't even understand the reasoning to do that.

Maintaining that kind of monstruosity of shell scripts that have to work on all kind of OS or linux distros must be a giant PITA compared to the simplicity of making an appimage/flatpak and a set of deb/rpm packages for the most popular distros and clear instructions for port maintainers to do the same for archlinux and BSD systems.

One should never pipe curl output into `sudo bash`, but I think you've got things quite backwards here. Barring some extreme edge cases, putting binaries in /usr/bin, icons in /usr/share/icons, config files in /etc, libraries in /usr/lib and so on, are standard across the the Linux workd, and simple utilities that are just archives of binaries, docs, and auxiliary files can easily be deployed to most distros with a common install script.

This is far, far less complex than having to maintain and distribute an entire bundled runtime environment, deal with inconsistent behavior with the local config, etc. Flatpak and AppImage have their use cases, but by no means are they simpler than just putting binaries in the right places -- they are in fact an entire additional layer of complexity.

Here's one I spotted a few weeks back, just so you know I'm not making shit up:

https://docs.waydro.id/usage/install-on-desktops (see Ubuntu section)

If it is not provided by the distribution, those things shouldn't go in /usr/bin|lib|share but in /usr/local/bin|lib|share

That's a reasonable practice, yes, if you're doing a manual direct install. In situations like this, though, I typically just write a quick PKGBUILD script so the package manager can manage it, which means pointing things at the direct /usr/* paths, not /usr/local/*.

I don't recall ever seeing this approach with sudo. Is it really becoming popular? It used to be just bash, e.g. `curl ... | bash`. But now there is nothing stopping you from putting sudo in that bash script and expecting with a high probability that NOPASSWD: is also there ;)

Indeed, if you preface the curl | bash with sudo apt install, there's no difference!

Reply on news.ycombinator.com