- cross-posted to:
- linux@lemmy.world
- cross-posted to:
- linux@lemmy.world
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).
You must log in or register to comment.
Why do you have to have this xor that? Why can’t I like both? I’m sure both have use cases where they work best.
Drop the hate already.
We have so many wheels in linux, just choose the one you like because some Linux user love to reinventing the wheel over and over and over again
This is what systemd is doing. Inventing a set of wheels suitable for most distros
Can someone explain the “we hate systemd” meme for me? I’m not exactly new to Linux but the context is lost on me. Does anyone actually hate systemd?
It oversteps because the creators found it to be convenient.
Copacking default services for networking and time synchronization and other systems with the init make sense for a specific usecase but god bless you if you need to use a different service as you track down the various configuration options to disable functionality.
It works amazing as a service management tool but the prebaked services it provides generally cause more problems than they solve.
I do.
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.
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.
Does anyone actually hate systemd?
It’s a little too monolithic and kitchen-sink-including for my liking. It doesn’t feel like the “do one thing and do it well” style, it has a pretty large attack surface as a result.
Oh, and binary log files.
It’s a little too monolithic and kitchen-sink-including for my liking. It doesn’t feel like the “do one thing and do it well” style, it has a pretty large attack surface as a result.
That makes sense. I could see how that would irk a lot of people, but I’d personally trust the widely used, intensely scrutinized, load-bearing, open-source processes, over a lesser known one.
Oh, and binary log files.
Yeah those are great… Or do we dislike those too? 🙃
There are a lot of command-line tools for text, like
grepandsed, that don’t work on binary files. Whether this matters to you depends on your workflow. (I usegrepa lot.)Just
journalctl | grepand you’re good to go. The binary log files contain a lot of metadata per message that makes it easy to do more advanced filtering without breaking existing log file parsers.
Every Linux user actually hates SystemD, but we pretend to like it to show superiority over other Operating Systems.
I wrote and maintained a lot of sysvinit scripts and I fucking hated them. I wrote Upstart scripts and I fucking hated them. I wrote OpenRC scripts and I fucking hated them. Any init system that relies on one of the worst languages in common use nowadays can fuck right off. Systemd units are well documented, consistent, and reliable.
From my 30 seconds of looking, I actually like nitro a bit more than OpenRC or Upstart. It does seem like it’d struggle with daemons the way sysvinit scripts used to. Like, you have to write a process supervisor to track when your daemonized process dies so that it can then die and tell nitro (which is, ofc, a process supervisor), and it looks like the logging might be trickier in that case too. I fucking hate services that background themselves, but they do exist and systemd does a great job at handling those. It also doesn’t do any form of dependency management AFAICT, which is a more serious flaw.
Nitro seems like a good option for some use cases (although I cannot conceive why you’d want to run a service manager in a container when docker and k8s have robust service management built into them), but it’s never touching the disk on any of the tens of thousands of boxes I help administrate. systemd is just too good.
No, but the weirdos who insist on spelling it “SystemD” always seem to hate systemd.
systemd is pretty great. I tend to start long-running processes as user services, and I’ve even taken to starting some apps that give an old laptop trouble with
systemd-runand a slice with some memory restrictions. Easy peasy, works great, all declarative, no wibbly-wobbly shell scripts involved.No, but the weirdos who insist on spelling it “SystemD” always seem to hate systemd.
“SystemD”
Having given a shot to OpenRC on Alpine systems, I would say that I prefer systemd for creating and managing services.
I like its unified logging, which extends even beyond the host, integrating the logs of nspawn containers. I like its tmpfiles, which allows configuring temporary files, without writing scripts that create/cleanup them.
I have to admit, however, that I don’t like all of its subsystems. For example, I don’t want networkd and resolved anywhere near my configuration.
I don’t hate systemd, but I’ll all for having alternatives.
I wonder what new does this bring into the table?
I mean we already have at least these in addition to systemd:
- OpenRC + openrc-init
- s6 + s6-rc
- runit
- Epoch
- dinit
- minit
- GNU Shepherd
- finit
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.
Hate Systemd?
No, I don’t :)
insert xkcd picture about standard
