1. 9

It is very long and detailed but the last 4 sections are short and also very interesting.

In this blog post, I have introduced a process manager-agnostic function abstraction making it possible to target all kinds of process managers on a variety of operating systems.

By using a single set of declarative specifications, we can:

  • Target six different process managers on four different kinds of operating systems.
  • Implement various kinds of deployment scenarios: production deployments, test deployments as an unprivileged user.
  • Construct multiple instances of processes.

Then under limitations there is a nice table that gave me some idea about the relative trade-offs of init-systems (something I hadn’t really thought too much about before).

He also compares his approach to pleaserun and dysnomia both of which I thought were interesting projects I hadn’t heard of.

Also his experiments with running nix on freebsd and cygwin are very interesting and I think his suggestion to try to keep nixpkgs compatible with stdenv-native is a very good idea and deserves some discussion.

  1.  

  2. 1

    This looks neat, though I’m not entirely sure that that’s an extra layer of abstraction that is really worth it.

    Two thoughts I had while reading:

    • I struggle with the idea of dependencies between nginx as a proxy and backend services. In particular, I would want to be able to reconfigure or restart both individually without taking down the other. If the dependencies are just about ordering initial start-up that’s fine, but I’m not sure all process managers handle it like that.
    • This doesn’t seem to deal with logging and/or capture of stdout/stderr at all. I’ve run into issues more than once where services, daemonized or not, ended up writing important diagnostic output to pid 1’s stdout (typically the console), not easily accessible and typically just lost on a server.