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).

  • Eyedust@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    5 hours ago

    I’m a very mid-level Linux user. I use systemd because I’m just not familiar with how init systems actually work. I love that the choice is there, but I think systemd has it’s place with users like me that get confused.

    That being said, I did run Dracut on EndeavourOS because it was recommended for that distro. I never dived into it to see what the exact difference was, though I do remember running into some things I needed to do that Dracut did differently. There may come a day when I dive into inits, but for now I’m just happy if my system starts.

    • TMP_NKcYUEoM7kXg4qYe@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      2 hours ago

      Dracut is an initramfs generator, not an init system. They do completely different things. You were still using systemd as an init system.

  • Quazatron@lemmy.world
    link
    fedilink
    arrow-up
    26
    arrow-down
    2
    ·
    19 hours ago

    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.

  • Arcane2077@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    50
    arrow-down
    2
    ·
    21 hours ago

    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?

    • Sprocketfree@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      7
      ·
      7 hours ago

      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.

      • neclimdul@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        5 hours ago

        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.

    • muusemuuse@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      4
      ·
      edit-2
      7 hours ago

      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.

    • Zucca@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      11
      arrow-down
      1
      ·
      15 hours ago

      Because systemd replaced too many important components users still wanted to keep using… and politics. Not many people like Lennart (the guy who started the project). Politics ruin everything.

      For me the breaking point was systemd-journald. Corrupted journal when you desperatedly needed to know what went wrong was too much. Last time I gave systemd a try was several years ago… Something like 5 to 7 years, so things might have changed a lot.

      Also I’m in the minority here. I like to custom my system components too. systemd just doesn’t fit there. Also I administrate one llightweight, low power box, which uses musl libc. Last time I checked systemd needed glibc.

      Enough ramblings. Here’s some reading for you… note that there’s most probably very biased technical writings here and there, so use common sense and verify the claims if you want the real truth. Then judge yourself, don’t let anyone else judge for you.

    • DigitalDilemma@lemmy.ml
      link
      fedilink
      English
      arrow-up
      9
      arrow-down
      4
      ·
      edit-2
      13 hours ago

      Two groups of people went to war over a difference of opinion.

      1. New! Different! Change! Bad!

      2. Hey, this works better than the old way. Let’s use this instead.

      • muusemuuse@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        2
        ·
        7 hours ago

        Dude if you want to start a holy war with the Linux community over your first point, just mention Rust.

        -dodges rotten fruit-

    • thatsnothowyoudoit@lemmy.ca
      link
      fedilink
      arrow-up
      37
      ·
      edit-2
      21 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
        link
        fedilink
        arrow-up
        7
        ·
        edit-2
        16 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
          link
          fedilink
          arrow-up
          3
          ·
          15 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.

    • Dave.@aussie.zone
      link
      fedilink
      arrow-up
      37
      arrow-down
      2
      ·
      21 hours ago

      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.

      • Arcane2077@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        11
        arrow-down
        1
        ·
        21 hours ago

        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? 🙃

        • nyan@sh.itjust.works
          link
          fedilink
          arrow-up
          11
          arrow-down
          1
          ·
          18 hours ago

          There are a lot of command-line tools for text, like grep and sed, that don’t work on binary files. Whether this matters to you depends on your workflow. (I use grep a lot.)

          • Badabinski@kbin.earth
            link
            fedilink
            arrow-up
            14
            ·
            17 hours ago

            Just journalctl | grep and 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.

    • procapra@lemmy.ml
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      14 hours ago

      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).

    • Auli@lemmy.ca
      link
      fedilink
      English
      arrow-up
      14
      arrow-down
      7
      ·
      16 hours ago

      People hate change and want Linux yo remain in the 70’s. Find threads complaining about any change in Linux.

    • Brosplosion@lemmy.zip
      link
      fedilink
      arrow-up
      9
      arrow-down
      1
      ·
      16 hours ago

      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.

    • Obin@feddit.org
      link
      fedilink
      arrow-up
      3
      arrow-down
      1
      ·
      edit-2
      16 hours ago

      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.

      • Cricket [he/him]@lemmy.zip
        link
        fedilink
        English
        arrow-up
        1
        ·
        11 hours ago

        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.

        • Obin@feddit.org
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          10 hours ago

          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. 🤷

    • MonkderVierte@lemmy.zip
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      15 hours ago

      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.

    • Pro@programming.devOP
      link
      fedilink
      English
      arrow-up
      11
      arrow-down
      18
      ·
      21 hours ago

      Every Linux user actually hates SystemD, but we pretend to like it to show superiority over other Operating Systems.

      • Badabinski@kbin.earth
        link
        fedilink
        arrow-up
        9
        ·
        17 hours ago

        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.

      • esa@discuss.tchncs.de
        link
        fedilink
        arrow-up
        12
        arrow-down
        1
        ·
        19 hours ago

        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-run and a slice with some memory restrictions. Easy peasy, works great, all declarative, no wibbly-wobbly shell scripts involved.

        • Pro@programming.devOP
          link
          fedilink
          English
          arrow-up
          6
          arrow-down
          5
          ·
          edit-2
          18 hours ago

          No, but the weirdos who insist on spelling it “SystemD” always seem to hate systemd.

          “SystemD”

      • jim3692@discuss.online
        link
        fedilink
        arrow-up
        6
        ·
        20 hours ago

        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.

        • Auli@lemmy.ca
          link
          fedilink
          English
          arrow-up
          2
          ·
          16 hours ago

          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.

      • Auli@lemmy.ca
        link
        fedilink
        English
        arrow-up
        1
        ·
        16 hours ago

        I like it. Good logging easier to write and trouble shoot start up scripts.

  • Zucca@sopuli.xyz
    link
    fedilink
    English
    arrow-up
    16
    ·
    edit-2
    21 hours ago

    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. 👍

    • Badabinski@kbin.earth
      link
      fedilink
      arrow-up
      4
      ·
      17 hours ago

      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.

      • TMP_NKcYUEoM7kXg4qYe@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        2 hours ago

        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)

      • Zucca@sopuli.xyz
        link
        fedilink
        English
        arrow-up
        1
        ·
        15 hours ago

        Initial commit on Oct 21, 2023

        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. 🤔