Hacker News Reader

Comment by anonymous | Hacker News Reader

No, it's not. I only see it on the odd hip-n-cool project by people with less experience than my server's uptime. Everything I install is either from a distro's package, from a tarball or by compiling from source.

I don't mind having a script that sets up the environment, there is a lot of software out there that does have these set up scripts in the tarball, or is distributed as a self-extracting archive, but you can always see it is marked as such. What I really balk at is "run this random script, trust me it installs". Would it kill them to write "download this script which will run apt-get pkg1 ... pkg10, then extract an inline tarball to ~/.local/lib"? I'm not going to run a random script that I have ZERO idea what it will do. It's not about security, it's about knowing that a good-intentioned non-compromised script won't crap all over my environment.

View on HN

If you want to know what the script does, reading the script would be the obvious solution. Why should this program's author hold your hand and explain the script in prose when the script clearly explains itself already in its own language? The guy isn't demanding that you run it blindly. Maybe he figured anyone smart enough to write Prolog programs is smart enough to understand the implications of downloading and running a shell script.

It will be ok in most cases... until it won't. What this script does is install dependencies. And fails for anything that isn't the most popular system. I really don't see the point of writing a script like this, as opposed to the following text:

    Requirements: git, prolog (package swi-prolog-nox, or swi-prolog).
    To install checkout repository https://github.com/larsyencken/marelle and run "make install" (optionally with DESTDIR=/your/custom/destination/path).

Less writing, clear instructions and provided you know how to write a standard well-behaved makefile, it will also not assume surprising things about your system. Also they could ship the bin file without a static path in their repo instead of creating it on installation for some reason.

Those bootstrap files are really annoying me - also because they assume zero knowledge from the user (even if that user is supposed to later write system standup script in prolog... oh the irony). It also gets completely redundant sometimes - like the composer in php (https://getcomposer.org/installer) - it's a php script that includes loads of logic to download a single file and put it in the correct directory. And it's not an unusual case.

I really believe the bootstrap scripts are both useless and harmful, apart from a very few special cases.

Many of these scripts run on to pages, particularly if they attempt to cope with multiple systems. Tracing through what they do can be a real pain.

(My personal policy is that anything that asks to be installed this way does not get the script run as root, and does get its own uid, so that neither it nor anything it installs can read me uid. This does mean I'm stuck on an old version of rvm, since newer ones seem hell-bound to upgrade my apt infrastructure, and I've found no easy way for me to figure out what exactly it's trying to install, let alone what else it might do behind my back.)

If you read the page, right under the quickstart script is the manual version describing all the same steps yourself. This indicates precisely what the script does, and leaves it to you to decide if you want to run it or just do the steps yourself.

That was the quickstart version—it's just being pragmatic. The alternative is to audit the setup script yourself, which is easy enough to do. You'd do the same for a tarball right?

If you trust the author and want to get started quicky it makes a lot of sense to simplify the install process to a one liner.

Reply on news.ycombinator.com