Make NixOS systemd-independent

[Kreyren]

Issue description

Tracking to make NixOS systemd-independent, because freedom of choice matters

Known issues with systemd

Demanding on system resources

On my system using any minimal systemd linux distribution including NixOS forces my CPU to hold +- 3 Ghz (compared to 0.6 Ghz on optimized Exherbo system) at low utilization due to systemd-related services such as systemd-journald causing spikes of up to 12% utilization at random intervals.

Stop jobs

Systemd is notorious at wasting time during boot and shutdown by forcing wait for "Stop jobs" that has major impact on production

Monopolization

Systemd creates a close ecosystem of software that is depending on it's built-in functions which breaks software such as gamemode by Feral Interactive https://github.com/FeralInteractive/gamemode that is harmful to the Free Software movement (https://www.gnu.org/philosophy/when-free-software-isnt-practically-superior.html)

Not modular

Systemd creates itself into a system manager overtaking the core functionality of the operating system which harms the Free Software Ecosystem by restricting the end-user on how they want their system to work e.g. forcing the use of systemd's eudev, elogind, etc.. instead of being modular for alternative implementation on demand

What needs to be done

To be determined

Related projects

• NixNG https://gitea.redalder.org/Magic_RB/NixNG

[lovesegfault]

I highly doubt there is interest in doing this.

If anything, we're working to use systemd more in NixOS, not less. There are ongoing efforts to use systemd in early boot, as well as replacing the scripted networking with systemd-networkd.

IMO any effort to have NixOS without systemd would, at this point, come in the form of a fork and not expect, or demand, any upstream support.

I'll let other maintainers chime in, but I believe we should close this issue as wontfix.

[Kreyren]

If anything, we're working to use systemd more in NixOS, not less. There are ongoing efforts to use systemd in early boot, as well as replacing the scripted networking with systemd-networkd.

I don't think that this implementation would prevent anyone from using systemd more rather allowing to also use other inits instead of limiting the user

[lovesegfault]

If anything, we're working to use systemd more in NixOS, not less. There are ongoing efforts to use systemd in early boot, as well as replacing the scripted networking with systemd-networkd.

I don't think that this implementation would prevent anyone from using systemd more rather allowing to also use other inits instead of limiting the user

Sure, but it would burden everyone to maintain things for systemd and not systemd. It would also increase the overall complexity of the current NixOS code by making us maintain two parallel "worlds."

It's not impossible, but as other distros have shown (Gentoo, Devuan) that it's a lot of work. I have not seen any interest among the maintainer base of NixOS to suggest there are enough people willing to do all the work to enable this, and then to maintain it long-term.

[Kreyren]

I would also like to address the concern that maintaining two init systems would be too maintenance demanding while pointing out Devuan GNU/Linux, Gentoo Linux, Exherbo Linux, etc.. who arguably have less resources compared to NixOS so from my experience it's all about implementation and even unofficial support allowing those who wants this functionality in NixOS would open door to cooperation

[Kreyren]

For reference making the packages to work on OpenRC is can be automatized through the various translators e.g. sysd2v https://github.com/RosstheRoss/sysd2v

I've implemented compatibility for OpenRC in oxen that way: oxen-io/oxen-core#1395

[lovesegfault]

I would also like to address the concern that maintaining two init systems would be too maintenance demanding while pointing out Devuan GNU/Linux, Gentoo Linux, Exherbo Linux, etc.. who arguably have less resources compared to NixOS so from my experience it's all about implementation and even unofficial support allowing those who wants this functionality in NixOS would open door to cooperation

All those are more counter examples than anything else:

• Gentoo devs actually do have to spend time maintaining the split SystemD / OpenRC setup. As a Gentoo user this is particularly painful in the documentation/wiki which often has instructions for one, but not the other init system.
• Exherbo is just too different from NixOS. They are (willingly, by design) tiny and have a "every user is an Exherbo developer" philosophy. Also, they inherited this duality from Gentoo, so the same caveats apply.
• Devuan is proof that it's not trivial to "have it both ways." It's so much work that they forked the whole distro since upstream wasn't willing to do the upkeep.

As it is, I believe NixOS is already flexible enough for something like this to be maintained out-of-tree as a set of modules, or as a fork. I do not believe there is enough interest at this time to maintain something like this in-tree.

[Kreyren]

Gentoo devs actually do have to spend time maintaining the split SystemD / OpenRC setup. As a Gentoo user this is particularly painful in the documentation/wiki which often has instructions for one, but not the other init system. @lovesegfault

From my experience the documentation is rather Gentoo devs not caring about the documentation as the compatibility is just about handling in package manager which providers the service files which when i was making gentoo packages was always painless to integrate

Devuan is proof that it's not trivial to "have it both ways." It's so much work that they forked the whole distro since upstream wasn't willing to do the upkeep. @lovesegfault

Debian has anti-openrc policy (afaik) due to their ties to RedHat they woudn't integrate it even if it was self-maintaining (even though they merge patches making the packages systemd-independent) thus why Debian developers left and make their own distro that makes minor changes in the packages and overwrites those in debian repo which is to this day a small group of people (like 4?) doing the work... So I find that a good evidence that systemd takes more resources to maintain due to it being over-complicated.

As it is, I believe NixOS is already flexible enough for something like this to be maintained out-of-tree as a set of modules, or as a fork. I do not believe there is enough interest at this time to maintain something like this in-tree. @lovesegfault

That's how it's done currently in NixNG which is difficult to find and coordinate, having this in-tree would make everything better

[figsoda]

Related issue: #24346

[lovesegfault]

From my experience the documentation is rather Gentoo devs not caring about the documentation as the compatibility is just about handling in package manager which providers the service files which when i was making gentoo packages was always painless to integrate

I find it kind of callous to suggest Gentoo devs don't care about their docs. In my experience as a user for a few years now this is definitely not the case. Regardless, out of scope for this project.

debian repo which is to this day a small group of people (like 4?) doing the work... So I find that a good evidence that systemd takes more resources to maintain due to it being over-complicated.

There are way more than four people maintaining Devuan: https://www.devuan.org/os/team

Even if it were only four, I don't think there are four NixOS developers interested in supporting OpenRC.

That's how it's done currently in NixNG which is difficult to find and coordinate, having this in-tree would make everything better

I don't believe this claim to be true. It would make things better for a small subset of the community interested in this feature. In exchange for this, the entire developer base would have to be burdened with supporting both SystemD and OpenRC.

To make my point abundantly clear: I am not saying there is no value in getting rid of SystemD. It is not my place to say what is or isn't worth it for you, or others. I am, however, saying that there is no interest at this point in time to maintain such a feature in NixOS.

This has been discussed in length in #24346, so I will be closing this issue. If a subset of NixOS maintainers is interested in pushing this forward they should probably write an RFC (https://github.com/NixOS/rfcs) and have the discussion take place there.

[MagicRB]

Hi, I'm the maintainer of NixNG, I believe that pursuing any kind of init system agnosticism in NixOS is madness. NixOS relies on systemd way too much and all the services + many other things smell systemd-y, if we were to take those modules and just stick openrc underneath the end result would be horrible scripted mess. (That's exactly what happened to NixNG, though its using runit instead of openrc). That's just my two cents here.

tl;dr: maintaner of NixNG here, against multi init in NixOS too complex and wasted effort

[appetrosyan]

I second the opinion that the same effort would be better spent on helping NixNG become a thing.