GitHub - leahneukirchen/nitro: tiny but flexible init system and process supervisor
github.com
tiny but flexible init system and process supervisor - leahneukirchen/nitro

cross-posted from: https://programming.dev/post/36342010

Nitro is a tiny process supervisor that also can be used as pid 1 on Linux.

There are four main applications it is designed for:

  • As init for a Linux machine for embedded, desktop or server purposes
  • As init for a Linux initramfs
  • As init for a Linux container (Docker/Podman/LXC/Kubernetes)
  • As unprivileged supervision daemon on POSIX systems

Nitro is configured by a directory of scripts, defaulting to /etc/nitro (or the first command line argument).

  • thatsnothowyoudoit@lemmy.ca
    33·
    8 hours ago

    It was highly contentious for a number of years - largely because it had a lot more functionality and touched more parts of the OS than the init systems it was designed to replace. It was seen as overzealous by the naysayers.

    I was in the never system-d camp for a long time because I felt like my ability to choose was being removed. Even some distros that provided alternate init systems eventually went systemd-only.

    But I’ve come around - it’s fine, good even - though ultimately I had no choice or say in it.

    It’s very straightforward and easy to write one’s own units. It’s reasonably easy to debug and often helpful when something isn’t working as expected.

    Like all things in the world of software, many folks are going to try (and eventually succeed) to make a better mousetrap.

    This particular init system’s design goals seem (at least to me) to indicate a focus on small, embedded and/or more secure systems where the breadth of tools like systemd are a hindrance.

    • TheFrogThatFlies@lemmy.world
      3·
      3 hours ago

      IMHO systemd tries to go above the requirements of an init system and behave more like an abstraction layer to the OS, in the same way Linux is an abstraction layer to the hardware. Would we be better with a micro kernel, instead of the Linux beast? Maybe, but we do all use it and it is mostly a standard nowadays. Same for systemd. Could it be simpler? Sure! But having a standard abstraction layer at user level for all distros is excellent for an app developer. And, AFAIK, it should be possible, albeit less verified, to disable most features and use alternative implementations.

      • thatsnothowyoudoit@lemmy.ca
        1·
        2 hours ago

        Totally fair and exactly part of my original disdain. I was happy with SysV and Upstart. But here we are and I’ve got things to do. ;)

        I hated repackaging all my software for systemd. lol. We waited as long as we could before eating that pie.