Shepherd × Goblins update — Spritely Institute
spritely.institute

The Shepherd is an init system and process manager initially built for GNU Hurd and now used by Guix. It can run with either root or user privileges to launch daemons, execute tasks, and manage processes. As we’ve discussed previously, Spritely has been working to port the Shepherd to Goblins. We’ve been a bit quiet since that announcement, so what’s the buzz?

First, as a quick refresher, the Shepherd is a great project to port to Goblins because it’s already built on the actor model. By switching to Goblins, we can bring the following benefits to the project:

  • Streamline the codebase by replacing the Shepherd’s ad-hoc actor model implementation.
  • Reduce the likelihood of concurrency bugs caused by the existing actor model implementation that exposes too much of its CSP foundation using Fibers.
  • Transform services (and other actors) into object capabilities for fine-grained management of privileges, which will (eventually) make it to possible to unify the currently separate worlds of “system” Shepherds that run as root under PID 1 and “user” Shepherds that run as an unprivileged user.
  • Enable Shepherd to use the Object Capability Network (OCapN) to open the door for distributed networks of “Communicating Shepherd Processes” in the future.

Since our last post, we’ve done the following:

  • Wrote Goblins versions of the core actors like the service controller, service registry, and process monitor.
  • Added unit tests for all of the core actors (there were none before).
  • Rewrote the public API as a compatibility layer on top of a new Goblins actor API. This new API is private for now.

What this means is that all of the extant Shepherd functionality will soon be available in the Goblins port. We’re currently working out the remaining sneaky, tricky, subtle bugs in order to have a full 1:1 port that passes the existing test suite. We’re getting very close, so we felt it was time to share this update!

    • wheresmysurplusvalue [comrade/them]@hexbear.netOPEnglish
      2·
      1 month ago

      Didn’t know that, that’s a shame. I’m mainly interested in what kind of deployment tool might end up being developed from this and maybe provide an alternative to NixOS deployment tools.

    • thetaT [none/use name]@hexbear.netEnglish
      1·
      1 month ago

      well, that’s sort of where they get their funding. you can’t bite the hand that feeds you, you’ve got to be practical about these things.

      plus, i don’t it’s correct to just be completely anti-crypto - while the technology as a whole in general is a sham and a scam, it can be useful to have anonymous payments if you’re doing things like building a resistance network and you need to move funds around anonymously over long distances. it’s one of the ropes the bourgeoisie will sell you to hang them with. it’s similar to how one might oppose killing in general but recognise its necessity in a class war.

      • kim (she/her)@lemmy.mlEnglish
        1·
        1 month ago

        taking money from the crypto industry isn’t a requirement to work on an open source project in a meaningful way. i would know, i maintain a well known open-source project in the same ecosystem for which we receive a grant (and so do they! they’re receiving from the same fund). and previously we worked for multiple years on our project around regular jobs. yes we could reach out for better funding opportunities working with people we don’t agree with, but we have a moral backbone lol.

        if you read the “proof of forestry” Google groups link authored by Christine you’ll see she’s not looking at (or working with) the crypto industry in any kind of useful context.

        edit: i’m sorry if this reply comes off as a bit hostile. i’m just tired of so much of the software industry being spineless complaining about how shit companies are while actively contributing to them because it comes with a nice round paycheck.