How possible (or how non-trivial) is it to restructure NixOS (or a branch) so that it can work without the systemd package?
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â).
16 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 
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