1. 13
  1. 6

    This is hilarious because a much less-well known system (baserock) with a very similar goal to Nix had a tool also called morph that predates this one by several years. Baserock was kind of parallel to NixOS but not nearly as successful, in the end morph died, but out of its ashes came a tool called buildstream which seems to be more successful.

    edit: clarify

    1. 2

      thx for pointing to be buildstream. Seems like an excellent tool to build cross-os compatible packages. I was looking for something like this actually

    2. 3

      I’m always interested in tools like this. My first question however is: there appears to be quite a lot of overlap between Morph and NixOps. I currently use NixOps. Why might I instead use Morph?

      1. 1

        I asked a while ago on HN:

        It doesn’t maintain any state - NixOps uses SQLite database which makes it cumbersome to share with other devs.

        Morph can’t create machines for you - it doesn’t have any backends except for SSH. It means fewer dependencies but you need to create targets manually or with something like Terraform. I’ve only used ‘libvirt’ and ‘none’ backends with NixOps and even wrote a ‘dumb’ backend that unlike ‘none’ backend wouldn’t generate and store SSH keys in state but respects .ssh/config.

        One feature of morph is really nice - declarative health checks that are run after the deployment automatically or can be triggered manually.


        1. 1

          It looks a lot like it’s formalizing the approach @vaibhavsagar described in this article (and a couple other blogs it links). It sounds like there’s some folks working out a different approach to the same problems NixOps solves.

          1. 2

            That’s what I thought too, but I did wonder if there was something else I was missing. I always welcome alternate approaches to problems, it just also helps to understand the motivation (so it’s not just a case of NIH).