Restructuring NixOS to work without systemd? e.g., with SysVinit

How possible (or how non-trivial) is it to restructure NixOS (or a branch) so that it can work without the systemd package?

5 Likes

Hi and welcome to the forum!

@pxc summarized the history and state of affairs as follows:

Note that the complexity lies both naturally in the problem of what service management at an abstract level really is and has to do, as well as the specifics of how NixOS is tied to systemd.

6 Likes

It’s probably just going to get harder, too. The initrd is slowly being migrated to systemd as well.

2 Likes

I think the ship has sailed for NixOS to use anything other than systemd. I’m not just saying that because I quite like systemd; NixOS is just actually quite heavily dependent on it at this point. I think it’d be really cool to see alternative distros built with Nix that use other systems and provide NixOS-compatible modules for non-systemd-related options. But I do think those would effectively have to be one or more “new distros” (there’d be a ton in common with NixOS so it’s weird to say “new distro”).

15 Likes

In the tone and spirit of what @fricklerhandwerk said, I want to add that service management / scheduling has probably seen unprecedented expansion of it’s domain ranging from cluster/data-center schedulers (mesos, k8s, nomad) to development environment service managers (docker-compose, foreman, hivemind, etc).

NixOS, in and of itself, is a superset of a service library.

Service Managers probably always have some common (and in principle abstractable) interfaces. If clarity is produced, that might not even be too hard. Such generic interfaces are probably:

  • Capabilites-based Scheduling (including resources)
  • Liveness & Readiness
  • Dependency Management
  • Environment Preparation
  • Capabilities Management (in isolating schedulers)
  • Upgrade/Migration paths (sometimes)

Finding an interface that could sufficiently satisfy the subset of the common denominator between the various implementations, might actually not even be too hard. It would be a subset that would forgo some scheduler-specific features.

It would make the above mentioned service library potentially extremely more useful. And would probably also help tear down some current ecosystem boundaries: e.g. have a service library for X thousand services across k8s, nomad, sytemd would immitate the enormous business value that the Nix Package Collection already provides, just for services.

Migrating nixpkgs/nixos is another beast, of course, as may it be finding an interface that provides scheduler specific escape hatches…

3 Likes

How possible (or how non-trivial) is it to restructure NixOS (or a branch) so that it can work without the systemd package?

systemd, as in “systemd-as-pid-1” or “systemd-the-project”?

Because SysVinit is really only a substitute for the former. And replacing systemd with sysvinit would of course be entirely doable. It would be a lot of work and it would take features away but sure, you could do it. Some of the questions are “what problem are you trying to solve by changing” and “will this fragmentation do us any good (as a project) or harm us in the long run” so I’m guessing the chances of it happening are very slim.

As time goes by and we start depending more and more on the features provided by the systemd project, the harder it will be to change of course.

I’d be super curious to hear the justification for such a change though.

7 Likes

Then again, to follow the trail on it, this gives a nice overview:

https://www.youtube.com/watch?v=6a2NOvod_MY Disnix NixCon 2015

https://www.youtube.com/watch?v=7xDVTflSrdU Dysnomia NixCon 2018

https://www.youtube.com/watch?v=N9Dygq4Lz0c - Nix processmgmt NixCon2020

4 Likes

And there is DisnixOS :wink:

1 Like

Realistically, I don’t think it will ever happen. Most of the NixOS options provides only a very slim layer of abstraction above systemd and many are 1:1 mapped to systemd options.

We also rely on much more than just the init and journal: containers, boot loader, file systems, logins, device dependencies, udev, and more. Some modules do have two alternative implementations, like networking-interfaces.nix, so it’s doable but it’s such a massive effort and most people don’t care about alternative inits.

4 Likes

The NixOS init system has been replaced before and it will certainly be replaced again.

6 Likes

Yeah, around 2011, right? NixOS was pratically an experiment back then.
Today it’s necessarily going to be much more difficult: there are probably 10x the modules and most services are tied to systemd hardening mechanisms like DynamicUser, ProtectSystem and PrivateTmp which we would have to drop (lowering the security) or reimplement.

As much as I don’t like the leadership and many design decisions of systemd, it’s extremely useful for NixOS and replacing it doesn’t make much sense. It would be interesting to make the init configurable, particularly for embedded devices with few resources, but it would probably mean losing most of the services we have now.

5 Likes

Could be. If there is a distro that can do so it’s NixOS, given the levels of abstraction involved. It’s still very hard to see this happening anytime soon, if at all, given the effort it would be and the limited drive behind such a thing at the moment.

2 Likes

Is it not too short-sighted or semantically skewed to look at NixOS (i.e. systemd) as the only legitimate target of that massive Nix Module Service Library (i.e. nixpkgs/nixos/*)?

Of course, it depends on the presumed priorities. So let’s presume the goal is to make this library as generally useful and interoperable as the Nix Package Collection already is.

It probably won’t happen based on mere “scratching of itches”, given the current user base is cought in a local maximum of NixOS users, but a good vision and understanding of where we could be instead, might help drive some more thought.

DisNix is a nice “path-dependent” evolution, but it isn’t and won’t be capable of substituting interoperability with other very rich scheduler ecosystems.

2 Likes

This is the thing— ‘it’ (the NixOS module system being used in other ways and with other services managers) has already happened— that’s what Nix-Darwin and Home Manager are. (In one case it’s a different service manager, and the other it’s systemd but not a systemd instance managed wholly by Nix.)

The actual question is whether/where/when such efforts will be integrated so that they can share code and a uniform user interface, not whether they’ll ever exist or have users and contributors. ¯\_(ツ)_/¯

8 Likes

A systemd replacement doesn’t need to implement all of systemd, nor would it have to be compatible with every module from the beginning.

In NixOS, we are empowered to have experimental things hidden behind an option without disturbing non-experimental users. See for example how easy Pipewire is to integrate.

A microcosm of this is the initrd for which we currently have a custom micro init system. Experimentally, there is also systemd for the initrd, behind an option. The two can coexist and be developed further without interfering with another.

OTOH though, there isn’t that much of a need for a non-systemd init anymore as the only other platform we could see a port of NixOS for in the near-ish future is FreeBSD for which a systemd port in the works.

1 Like

Right, the necessity for a uniform interface is absolutly evident.

Still, it is important to take a conscientious look beyond the boundaries of the Nix Ecosystem and envision the potential value that — in casu — a “Nix [Unified] Service Library” could offer to the world.

Provided that interoperability was to become a deliberate priority, rather than a side effect of “scratching itches”.

2 Likes

I would still very much like to hear what problems @menuhin thinks would be solved by adding support for multiple init systems/ripping systemd out in favour of something else.

Probably easier to address those than adding support for something else. And then testing that. And making sure that things don’t break. And keeping up the development/release velocity.

7 Likes

I fail to see the improvement by replacing systemd with fiddly pile of shell scripts.

Removing only the systemd package is quite possible if you are on another distro or operating system like MacOS.

4 Likes

A lighter and simpler design, due to the omission of systemd

Those claims only hold true if you need parts of systemd like in a container. If you are going to replace every function of systemd with its own project then you have a more complicated, harder to maintain and less integrated software stack.

11 Likes

The way systemd takes up the “responsibility of further providing features” make the life of developers and system admins perhaps easily.
But as the complexity of systemd builds up, it’s becoming alarming. And while we are all depending on it because of convenience, similar projects such as launchd of MacOS while handling jobs in similar ways, has only around 30K lines of code while systemd has well over 1M lines of code, and it is still continuing to engulf other functions. Further information: UNIX Version 7 was a complete, production-quality operating system written in about ten thousand lines of code.

There are endless number of patches to fix errors during the development of systemd (e.g. widespread outage caused by systemd), and as the vulnerability both in failing and in being attacked of a system correlates to its complexity, this one single pillar that everyone relies will inevitably fail one day. But then the problem is the way to “building a way out” of this MS-registry like style will probably be even more difficult.

1 Like