- cross-posted to:
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
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.
God help me if I ever feel this passionate about systemd.
What’s the point of all of these init systems if all we ever get are systemd services? You have to manually supervise all services if you’rw not using systemd which is really annoying.
I got used typing “sudo service --status-all”
then got used to typing “sudo systemctl list-unit-files --type=service”
now a new one to learn “sudo nitroctl list”
looks simpler
That can only be a good thing for my gnarly arthritis fingers.
Whatever works for other people I guess. A good Linux administrator is a person who can work with the default configuration on their OS, and I am trying to be that person and eventually learning inside-outs of systemd.
I’m getting to old for this shit
I love
systemd!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?
Systemd is a very good chunk of code. It does the thing and it does it well. Nobody is arguing that systemd does a bad job at this point.
The problem is systemd does a LOT of things that used to be individual jobs handled by separate things. This is a potential security problem as it makes systemd a fantastic target. It’s in charge of so many things that if you pwn systemd, you can get that system to do anything you want.
Another concern are the ties to red hat. Red hat is not your friend. They are not to be trusted. Especially not right now. Remember who owns them, IBM, were quite friendly with the Nazis before and are looking like they are totally fine with being friendly with them again.
That last one is more of a tinfoil hat concern than a technical one, but at this point the tinfoil crowd have been proven right more often than wrong so it’s something to consider.
So I should hate systemd because IBM’s German subsidiary provided tabulation machines to the Nazis during WW2?
That is not what I said. Please reread my post in its entirety.
Seems completely reasonable /s
Because it tries to do too much. Boots can fail because some random thing is broken. Just goes against the unix philosophy of a tool for a specific job.
This. Init having a pretty important role, you would hope being simple and minimal would be a priority. I just try to stick my head in the ground and pretend like it’s all ok.
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.
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.
Two groups of people went to war over a difference of opinion.
-
New! Bad! Different! Change!
-
Hey, this works better than the old way. Let’s use this instead.
You could equally mischaracterize it the other way around:
- Hey, this works worse for my workflow than before. I don’t want to use it.
- New! Different! Change! Good! Put everywhere!
Fair, and representative of some opinions certainly.
But change, change is constant. Resist it and end up poorer and more bitter.
That can be true… but it depends on the change… emptying your bank account is a change that would make you poorer, and having all those who love you die would be a change that is likely to make you bitter (or at least, sad).
Also, a lot of ancient software introduces change with relatively frequency… the Linux kernel itself is in constant change, introducing new features, despite it having very strict rules concerning backwards compatibility.
The reason there was disagreement wasn’t about whether the new thing is good/bad just because it’s “New! Different!”… but about whether it was actually a good change or not.
In the same way, just because nitro is the new init system in town (a change from the current status Quo) does not mean it necessarily is better/worse, right?
Also, I remember that before systemd there was a lot of innovation when it comes to init systems… most distros had their own spin. And more diversity in components that now are part of systemd. I’d argue that ever since systemd became the de-facto standard, innovation in those areas has become niche. One could argue that there’s less change now, distros are becoming more homogeneous and more change-adverse in that sense.
Dude if you want to start a holy war with the Linux community over your first point, just mention Rust.
-dodges rotten fruit-
I am a linux noob but all the noobs support rust
Everyone should support rust. It’s a good idea. It prevents an entire class of vulnerabilities. But the old guard says “just stop making mistakes and C is fine” which is an incredibly dumb thing to say but here we are.
Rust is encroaching on their territory and they don’t want to learn the new thing, and newbs don’t see many compelling reasons to learn the old thing, so they are fighting eachother.
-
People hate change and want Linux yo remain in the 70’s. Find threads complaining about any change in Linux.
On a modern system built around modern philosophies, its convenient. Doing stuff on systemd seems very intuitive to me and feels like a bit less work than the alternatives (atleast from my non-developer POV). If systemd hadn’t become the standard maybe my opinion would be different, but most of the time it “just works”.
On an older system, the alternatives are definitely lighter! If you’re in the group of people who believes every megabyte counts, you care about systemd. There are also oldschool tech nerds who believe systemd is insecure (they might be right idk anything).
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.
No, it’s just something systemd proponents claim to shit on alternatives and their users.
Sure, I dislike systemd or at least some of its components and how they’re designed, and I find the vocal systemd proponents (especially those that still find the need to be vocal about it in 2025) to be some of the most annoying people in the entire Linux community. But I use it on some systems and it works fine for the most part. Hate is a strong word for a software choice.
There was endless drama for years surrounding systemd when it first started getting adopted by distros. I recall people hating it with a burning passion. Slashdot had tons of such sentiment back then.
I don’t disagree that there was drama, I disagree about who was (always) the side fanning the flames. Systemd made divisiveness the core of its marketing strategy. Early on LP personally set the tone by calling out people and distros not using his software as Luddites. And that was back when systemd actually was still a buggy mess. And to this day, in threads like this you will see detractors explain the reason why they’re still opting out or have in the past, while (some of the) proponents will insult people opting out as backwards idiots who “don’t want to learn new things” or irrational haters. 🤷
I see. I wasn’t aware of that part of the story. Thanks.
Can’t have it with any alternative init and rc in the same repo or do this and fiddle with wrappers and shims. Yees, OpenRC is the exception; because it was built as a drop-in and only does rc really.
In short, Systemd is a kraken that always grows arms. And they shit code like me after Taco Bells; it took years until we got seatd as alternative to way-too-big logind. Xorg is holy compared to their code quality.
I do.
Every Linux user actually hates SystemD, but we pretend to like it to show superiority over other Operating Systems.
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 love networkd only issue is lack of documentation. Still can’t believe so many systems are using an unmaintained DHCP client. One of the reasons I even bothered is I didn’t like using the unmaintained one.
I like it. Good logging easier to write and trouble shoot start up scripts.
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.
I don’t hate systemd, but I’ll all for having alternatives.
Hate Systemd?
No, I don’t :)
OpenRC works just fine for me
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
insert xkcd picture about standard