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).
I wonder what new does this bring into the table?
I mean we already have at least these in addition to systemd:
The state being stored in RAM seems like a nifty feature. I like it.
Very quickly glanced… I think it lacks service supervision and user services. Although user services are missing in many others too. Except it looks like users can run Nitro by themselves (autostart via cron @boot maybe?). Somebody correct me if I’m wrong.
Anyway, more choices leads to more ideas being implemented. 👍
It also lacks any form of dependency management AFAICT. I don’t think there’s any way to say you depend on another service. I’m guessing you can probably order things lexically? But that’s, uh, shitty and bad.
This whole thing is basically runit + some extra features. So dependencies work the same as runit. You just check if the dependency is running. If not, you exit. Then the init will keep restarting the service until it works. (Just guessing based on the README)
If I’d implement a new init system, the dependency system would be one of the first on my TODO list. So… That’s strange. 🤔