Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Marelle: logic-based devops with Prolog

larsyencken.github.io

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Marelle: logic-based devops with Prolog

#11

Post by anonymous »

x1024 wrote: post #9
anonymous wrote: post #7

> Quickstart > Run the bootstrap script: bash -c "`curl https://raw.github.com/larsyencken/marelle/master/bootstrap.sh`" PFHAHAHAHAHAHAHAHAHAHAHAHAHAHA no

Ahm, that's the way to install pretty much everything these days. I mean, I know it's a security risk. But it isn't any more (or less) of a risk than installing nvm or just running git clone.

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.

Re: Marelle: logic-based devops with Prolog

#12

Post by p9idf »

anonymous wrote: post #11
x1024 wrote: post #9

Earlier quoted context omitted.

Ahm, that's the way to install pretty much everything these days. I mean, I know it's a security risk. But it isn't any more (or less) of a risk than installing nvm or just running git clone.

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 ca…

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.

Re: Marelle: logic-based devops with Prolog

#13

Post by dhotson »

anonymous wrote: post #11
x1024 wrote: post #9

Earlier quoted context omitted.

Ahm, that's the way to install pretty much everything these days. I mean, I know it's a security risk. But it isn't any more (or less) of a risk than installing nvm or just running git clone.

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 ca…

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.

Re: Marelle: logic-based devops with Prolog

#14

Post by viraptor »

p9idf wrote: post #12
anonymous wrote: post #11

Earlier quoted context omitted.

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 ca…

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 ru…

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.

Re: Marelle: logic-based devops with Prolog

#15

Post by rst »

p9idf wrote: post #12
anonymous wrote: post #11

Earlier quoted context omitted.

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 ca…

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 ru…

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.)

Re: Marelle: logic-based devops with Prolog

#18

Post by mcguire »

nodata wrote: post #2

This looks like scripting to me, not describing the desired state of a system: % we can install by running apt-get in shell meet(python, linux(_)) :- % could also use: install_apt('python-dev') bash('sudo apt-get install -y python-dev').

So, how do you describe how to install a package without looking like "scripting"?

Re: Marelle: logic-based devops with Prolog

#19

Post by lars512 »

nodata wrote: post #2

This looks like scripting to me, not describing the desired state of a system: % we can install by running apt-get in shell meet(python, linux(_)) :- % could also use: install_apt('python-dev') bash('sudo apt-get install -y python-dev').

You describe the desired state in your met block, or more properly, tests meant to indicate if your desired state is met.

Your meet block is the scripting which is supposed to get you there, but which is considered fallible. The met block checks after to see if it actually worked.

Re: Marelle: logic-based devops with Prolog

#20

Post by lars512 »

Hi guys, I'm the author. I've been playing with this for a little while, and trying to work out an idiomatic style for it. Suggestions for improvement are most welcome.

Some pleasant parts have been writing metapackage rules. For example, playing with Julia yesterday:

  % if P is a Julia package, it's also a general package
  pkg(P) :- julia_pkg(P).

  meet(P, _) :-
    julia_pkg(P), !,
    % install the package using the Julia interpreter
    ...

  met(P, _) :-
    julia_pkg(P), !,
    % try to import the package in Julia
    ...

  julia_pkg('PyCall').
  julia_pkg('DataFrames').
The only potential problem (on the horizon) is namespacing, which IMHO Babushka does well, but which is less obvious with Prolog's fact system.
Post reply on HN