Hacker News Reader

Comment by arbll | Hacker News Reader

A lot of those scripts are wrappers around package managers. Creating them is extra work for distributors, but they still do it because package-manager installs are not truly one-liners and offer far less control over the installation experience.

Users need to figure out which of the 10+ package managers they should be using, then run several commands. If something fails, the error messages are often cryptic and not easily configurable by the distributor.

And that’s before getting into the many rough edges of package managers. Most of them flat-out refuse to handle configuration and leave that part to the end user. Now you also need to document how to edit YAML and restart a systemd service. With an install script this is also solved.

For power users, this always looks trivial. In practice it raises the barrier to entry and can meaningfully affect adoption if your product is often used by less technical people.

View on HN

Your arguments do not make even a little sense.

In what world does a user have to choose between 10 package managers? Each distro has exactly one. There are also only about three, maybe four main package managers out there.

A shell script being piped into bash has so many more ways to break than a package. And if yhe theory is that package managers are fickle (they aren't), then how does adding more complexity help?

It is much simpler, much safer, and easier to maintain a package than an install.sh, eapecially for a big project.

Configuration can be handled by a script, yes. Here's a crazy idea: Your package can include scripts for configuring the software. It's almost as if most packages do. The scripts/utilities could even restart a systemd service for you.

Unless you're talking about configuring your build, in which case we're dealing with an experienced developer who will have no trouble just cloning the repo and building from source.

My biggest issue is: if we're dealing with someone who can't use a package manager, we're dealing with someone who doesn't have the capacity to judge how safe a script downloaded off the internet is. This does not drive linux adoption, it drives botnet adoption.

It's crazy to me that even after seeing so many major software distributors choose `curl | sh` as their entry point, people like you will still argue to the ends of the earth that there’s no problem with the package manager ecosystem.

I'll stop there. I'm not interested in continuing this discussion when it's being conducted in bad faith.

Bad faith, or perhaps just ignorance. It reminds me of purist junior engineers - and I have been one - refusing to understand or tradeoff in the world beyond their own.

Rather than argue with those of us who are pointing out messy realities, this commenter might be better served filing a bug against any number of the projects that offer installation this way, asking them to remove it, and see if it lands any better.

Technical purity/superiority isn’t the only factor, or even the most important one, driving projects to offer quick installers like this.

I would appreciate it if you would respond to me directly rather than suggest vaguely that I'm inexperienced and don't understand the realities of software distribution.

I would also appreciate it if you actually talk about something concrete rather than simply claiming to be right. You shouldn't pipe stuff from the internet into your shell.

Are you claiming that's about some highfallutin "technical purity"? Is it technical purity to check inside the bag when you buy a pig in a poke? No, that's common sense. It's common sense to have some degree of knowledge about what programs you execute on your computer. As root, at that.

Sure: I think you're essentially missing a whole set of concerns - ones that are not purely technical - behind why this method is popular; and so your arguments wouldn't convince someone actually responsible for one of these scripts to change or cease the practice.

Nobody would argue that it's categorically safe/good/smart to blindly pipe a script into your shell; and for the record, I agree. I would also readily agree that habituating users to doing this probably creates new, more general risks especially among how less-technical users interact with their CLI.

However, the realities of the "real world" make it popular for a reason, in light of those negatives; tons of scaled projects continue to offer a 1-liner. So we have to ask, why? They'd probably say that's because it (a) improves project adoption, and (b) reduces "install broken" tickets.

You have to address the non-technical merits and goals to get behavior to change here, and sadly, I don't think anyone has done that.

But who cares about me? I'm not currently maintaining one of these (though I did once). My suggestion to bring your argument to an active project was genuine: try it! I'd be delighted to see you bring about the change you want.

[PS: The commenter I replied to originally used the term "bad faith", which they've since edited]

The fact that people do something doesn't make it good.

I am arguing in good faith about the merits of the approaches. I am engaging with the points of argument being brought up from the opposing side of the argument (see above). I am not veering off on side-tracks, unlike you, for example.

There' a simple good faith argument (that I have been making) which you can try responding to: Running arbitrary code from the internet without checking is bad. There is some effort needed to package software, but that is not that much effort in the grand scheme.

It's about trust and having an official account for packaging on each platform where my customers getting their software from.

Most official repositories have policies that are incompatible with the needs of software vendors (release timing, supported versions, bundled dependencies, etc...).

IMO a lot of the blame falls onto the package manager ecosystem refusing to take into account very valid needs and claiming they aren't real / desirable.

Reply on news.ycombinator.com