Can I replace systemd with OpenRC or runit on NixOS?

[crocket]

I'd like to dive into NixOS right away, but systemd makes me hesitate.
Gentoo comes with OpenRC and presents systemd as an option.
To avoid systemd, I could install Nix on Gentoo or Void Linux, but that's not a proven track to me, yet.

I'd like to know whether it doesn't involve too much work for a poor user without a lot of time to replace systemd with OpenRC or runit on NixOS.

[joachifm]

The short answer is no.

[crocket]

Do enough people want to replace systemd with another init system in the near future?
The near future means 2~5 years.

Whether they have time or will to replace it is another story.

Ideally, an init system properly integrated into Nix would be preferable.

[vcunat]

There's a recent ML thread – it seems that a group of people wants to take action in that direction.

[0xABAB]

The more interesting question is whether a PR adding support for different backends would be accepted, since there are also costs associated with maintaining these additional backends.

I don't think it's a smart move to expand the scope of the project, since there are a lot of other issues still open.

@crocket I like some other init systems better than systemd, but at the same time do I see that systemd is good enough.

If an entity wants to commit development resources, then by all means do it. I might even use it, but I don't see init systems as a large differentiator to overall system performance (usability or otherwise).

[crocket]

@0xABAB Although it does the job at the moment, it carries a big risk of RedHat vendor lock-ins that will cost a lot in the long term. I might feel forced to use *BSD in the long term if vendor lock-ins abounded in linux distros in the future.

@vcunat Yes, I read that. I wanted to know whether a similar sentiment is shared by enough people that replacing systemd with another init system in the near future will be politically possible. It makes sense to make efforts to do something only if it is politically possible.

If it was politically possible and demanded, then I'd have more confidence in migrating toward NixOS.

[vcunat]

I don't know. I haven't seen that topic seriously discussed lately, except for that thread.

[0xABAB]

@crocket vendor lock-in is only a problem to entitities who do not understand software. Politically, I would like to rip out systemd too, if that was the question.

It's not as if systemd is obfuscated or completely undocumented. Additionally, I don't believe it's the case that RedHat has a proprietary version of systemd which works a lot better than the open-source version. So, if it's good enough for RedHat's customers, then it's good enough for me.

[joachifm]

Closing, as I belive the question has been answered, and I feel like the discussion is heading down an all too familiar path ... @crocket you may want to check out guixsd if systemd is a blocker; otherwise I think there's no way around writing some code yourself at this point (see runix, not-os, &c for inspiration).

[7c6f434c]

In some sense if you learn to use NixOS, migrating to not-OS or whatever spin-off without systemd there will be will be relatively cheap.

The core boot scripts are cheap to write manually, so you don't need that part to be accepted by larger community; the reason you want a larger community is for packages and services — NixPkgs is usable on Linux anyway, and NixOS supports exporting services as systemd-independent runner scripts.

You can look at
https://github.com/7c6f434c/7c6f434c-configurations/blob/master/init-less-system/generic/tools.nix#L373
This is a couple of helper functions I use to build a configuration on my notebook. Some systemd features actively break things I consider basic functionality, so I run some busybox scripts instead of an init system; the code I link allows me to reuse the parts of NixOS that I like without paying the cost of the parts I don't.

What I want to say is: even if you fail to convince people to merge changes into NixOS, the truly unmergeable part will be small and maintainable by a minimal team, and the large politically-neutral part of work can be shared between communities.

[globin]

I don't think anyone would be really opposed to having a service abstraction layer and that many would welcome it as long as it actually implemented cleanly :)

[crocket]

I like some other init systems better than systemd

@0xABAB I'm just curious of which init systems you prefer to systemd.

even if you fail to convince people to merge changes into NixOS, the truly unmergeable part will be small and maintainable by a minimal team

@7c6f434c It is economically infeasible for me to head a development effort. I'm not a developer.

I just wanted to know whether NixOS will accept replacement of systemd. It seems that the NixOS core team would allow replacement of systemd if a sufficiently large amount of manpower was directed toward it. So, I surmise there is a tangible possibility that NixOS will replace systemd in the foreseeable future. The possibility may or may not materialize. That's all I wanted to know for now.

I don't think anyone would be really opposed to having a service abstraction layer and that many would welcome it as long as it actually implemented cleanly :)

@globin systemd and OpenRC have different assumptions and different capabilities. It would be difficult to write a service abstraction layer that wraps around both systemd and OpenRC. I think writing a new init system for NixOS or just adopting any other simple init system might be cheaper. Or, just fork OpenRC, and use it in NixOS.

[globin]

I don't think we'd want to replace systemd, only abstract our services to a level where we can switch init systems quite easily.

[7c6f434c]

@crocket well, there are some such developments anyway, you could look at notOS keeping in mind that taking single services from NixOS is feasible. I think non-systemd NixPkgs-based system is or will be soon feasible for a user with skills in medium-complexity system administration; I expect that doing anything non-standard with NixOS is hard without these skills.

@globin or we can get one more enableParallelBuild story… (I hope we won't — maybe we will even fix the enableParallelBuild one eventually)

[crocket]

skills in medium-complexity system administration

@7c6f434c Can you define this?
Also, even if doing non-standard things was possible, it could continually cost a lot of time.

[7c6f434c]

Always hard to define such things… Well, configuring a Nix-based anything is writing simple scripts in a domain-specific language not used anywhere else, so I guess if you can comfortably use man bash as reference (you may still prefer some other source, of course), if «does any log in /var/log/ mention the config file you want to use» is a thing that you check without thinking too much about «how», such things…

[crocket]

That's not too difficult. When I said I was not a programmer, I meant I was no longer a programmer. I used to be a web programmer, and I also used to be a hobbyist system administrator who used to run a Slackware(which was a bad experience) linux router and submitted dozens of packages to AUR and SlackBuilds(Slackware's manual dependency resolution takes too much time!!). I have used linux for almost 7 years.

I have some competence in debian, ubuntu, docker, and FreeBSD. I started dabbling with FreeBSD again in a virtual machine after deciding to replace systemd over years.
I know how to write Haskell at a beginner/intermediate level.

After changing my career, my work doesn't involve programming or system administration at all, but I still do some programming and maintenance when I need to for system maintenance.

If that was your definition of medium-complexity system administration, I would qualify as one. Still, I have obligations to fulfill, and I can no longer justify pouring long uninterrupted blocks of time into system maintenance for more than a few days per month. I should work to eat.

I'm not a system administrator in the sense that I can no longer be a dedicated system administrator of medium-complexity for any meaningfully long periods of time.

If changing the init system didn't take too much time in the near future, I could try it.

[7c6f434c]

You definitely have the qualification to use and to meaningfully contribute (there are many one-off things requiring an hour or so in all the Nix* projects…), but I agree it is a good idea for you to check carefully which of the similar projects would take less effort for you to start using.

[crocket]

Can you recommend a potential approach to obtaining a non-systemd NixPkgs-based system without spending too much time in the near future? I have yet to learn Nix and NixOS, so I may not understand.

I just looked in /usr/share/systemd/system on my ArchLinux system, and I was scared by hundreds of init scripts in it.
Porting them manually alone would be a huge load of work. Anything that doesn't involve such a huge load of work is welcome.

Are there Instructions like http://systemd-free.org/migrate.php or http://systemd-free.org/install.php?

[7c6f434c]

I should try Not-OS before recommending or not recommending it, I guess… I would recommend maybe just using Nix-on-random-Linux to get some familiarity first anyway… If you can quickly write a bootscript (boot/mount/switch_root) for your system, trying something out can be done quickly, but otherwise I'd need to check out the project before recommending anything…

[crocket]

@7c6f434c https://github.com/cleverca22/not-os says

An operating system generator, based on NixOS, that, given a config, outputs a small (47 MB), read-only squashfs for a runit-based operating system, with support for iPXE and signed boot.

Thus, it is not for a desktop computer. RedHat is giving us an up-hill battle.

[7c6f434c]

Well, maybe if you skip the image → squashfs step… Will look at it at some point.

[ghost]

Thus, it is not for a desktop computer. RedHat is giving us an up-hill battle.

Precisely. They have also been both the major funders and adopters of systemd and other software stack solutions.

It is being increasingly difficult to avoid any of the larger corporations. Building another company/corporation will not change this but lead to similar problems.

I'd wish it were possible to all have distributed computer systems without being tied to any individual company per se. There are some who try to remain independent - slackware, gentoo. Others are following what red hat gives them.

[crocket]

I moved to gentoo a few months ago. I am grateful for freedom and customization options it gives me.

[brandondrew]

NixPkgs is usable on Linux anyway, and NixOS supports exporting services as systemd-independent runner scripts.

@7c6f434c So if I understand you, I could use NixPkgs on Slackware without any problem?

[7c6f434c]

> NixPkgs is usable on Linux anyway, and NixOS supports exporting services as systemd-independent runner scripts. @7c6f434c So if I understand you, I could use NixPkgs on Slackware without any problem?

I mean, I have yet to see a large collection of packages that can be used without _any_ problem, and of course there is some amount of NixOS-like assumptions sneaking in (tip: many of these can be mimicked on Slackware without damaging Slackware in any way, just create some strategically placed symlinks), but a lot of packages from Nixpkgs can be used on any x86_64 or aarch64 Linux as-is with the same experience as on NixOS just by straight nix-build or nix-shell.

[dm17]

I moved to gentoo a few months ago. I am grateful for freedom and customization options it gives me.

@crocket How do you do reproducibility on it? Darch (godarch.com)? Figure it is OK to ask you since this thread is closed :)

[crocket]

Gentoo downloads dependencies into cache directory before building. Building is done in an offline network namespace.
If build process tries to access network, build fails.
Dependencies are tied to hashes so that they cannot be altered.
So, you are going to get the same input every time.

By the way, I recommend artix linux for people who want a simple linux distribution where you don't have to build.
I may try artix linux with s6 init system because s6 looks interesting.

[dm17]

Gentoo downloads dependencies into cache directory before building. Building is done in an offline network namespace.
If build process tries to access network, build fails.
Dependencies are tied to hashes so that they cannot be altered.
So, you are going to get the same input every time.

By the way, I recommend artix linux for people who want a simple linux distribution where you don't have to build.
I may try artix linux with s6 init system because s6 looks interesting.

@crocket
I mentioned Darch because like NixOS it should allow for easily reproducible installations. I'm not as concerned with builds failing as reproducible installations and making "DevOps" easy. It should also work with Artix and all sorts of distros.

[appetrosyan]

The issue here is that nixOS uses systemd in a non mission-critical manner. Generations ran fine on grub, and systemd-boot isn't really systemd the PID-0. At the end of bedrocklinux/bedrocklinux-userland#221 there were a few examples of projects that managed to use a nixOS-like system, that didn't depend on systemd. Considering the strengths of nix this is likely the best way forward.

[0oAstro]

So what is current status? Can we use nixOS without systemd?

[7c6f434c]

So what is current status? Can we use nixOS without systemd?

No, NixOS mainline requires systemd and there are no signs of that changing,

[ketzacoatl]

Would NixOS governance be open to an effort to make this possible?

[ghost]

If you hate systemd that much and think it's some kind of monstorous crap, then you should use GNU's Guix system instead of NixOS because it uses the shepherd init system. Nix is directly integrated with systemd to boot up and manage daemons efficiently, and adding an extra init system will only make the developers cry as they struggle to implement a wrapper for them too.

[CamoCatX]

@crocket mentioned gentoo, and I know this is an old issue, but it might be worth looking at this overlay:

https://github.com/trofi/nix-guix-gentoo