7 ms·

Can you do NixOS without systemd? If not, I'd look elsewhere for the distro. Maybe Guix?

by b9be520d93286 5y ago

xyzzyz 5y ago
What would you prefer to have in Nix instead of systemd?
- NewJazz 5y ago
  I've been running Upstart (well, a fork I maintain) for over 2 years on my laptops and SBC. I'd like to use that. TBH I think NixOS might make it easier than other distros to run a custom init. I just haven't gotten around to importing my configs into a nix derivation.
  - md8z 5y ago
    If you have a parser for systemd unit files then you might have a chance to get that to work. If the whole reason you're doing it is to migrate back to upstart's syntax then it seems that would be not so useful, you might as well go in the other direction: write an upstart generator for systemd, and then you can just plug that into ordinary NixOS. Edit: Actually I think at some point NixOS did support upstart? Not sure whatever happened to that.
    - deleted 5y ago
      [deleted]
    - NewJazz 5y ago
      I'm not planning on working on anything related to systemd in the near future. If anything, I will write a config generator/type spec for startup/Upstart in Nix.
      - md8z 5y ago
        Unfortunately I think you probably will have to work on it if you want to not break existing configurations, so maybe NixOS is not for you. You could try alpine possibly? But with that you will have to do the same with init.d, so it's going to be somewhat of an uphill battle either way I guess. This is generally why I would discourage maintaining a service manager outside of an established distro, I tried to do it for about the same amount of time as you and it became not worth it. Upstart in particular has been basically entirely replaced by systemd.
        NewJazz 5y ago
        I already use upstart on void no problem. Alpine would be a similar deal with me just managing the configs as raw text files via rsync. In fact my fork is already packaged in Alpine. A few people use it as a session manager for sway. There is no chance that my Nix changes would affect existing configurations. They would be completely self contained.
        md8z 5y ago
        I mean if you want to run existing configurations on your setup. Those aren't going to work. You can just install Nix on void though. I had some users too but it still wasn't really worth it. I can't suggest it as a business model or a hobby project, you are basically going to be highly constrained by everything else on the system and your setup will just start looking like everything else eventually. Systemd also works fine as a session manager for whatever.
        deleted 5y ago
        [deleted]
- josephcsible 5y ago
  Literally any other init system. Maybe OpenRC, runit, or upstart? I'd even prefer to be stuck with sysvinit forever instead.
- b9be520d93286 5y ago
  I would prefer OpenRC, runit or something similar.
  - md8z 5y ago
    Those would probably be not so great matches for NixOS because they don't support the container stuff that systemd does, you would be throwing all that out.
    - NewJazz 5y ago
      Some people don't care. Some people want their boot ordering software and container runtime software to live in different code bases.
      - md8z 5y ago
        With cgroupsv2 there seems to be very little benefit to doing that since the container runtime needs to sit at the top of the process tree anyway, so I'm not sure I understand what the purpose of that would be or why you would want that. If you were using containers to run services then I can't really think of a situation where you wouldn't also want it as part of the boot ordering process, so your services will just have it working immediately upon boot.
        NewJazz 5y ago
        That is not true at all about cgroup2. Also think outside the box. Not everyone is using cgroups and namespaces. Some people are out there using gvisor, or KVM, or FreeBSD jails.
        md8z 5y ago
        I'm not sure what you mean it's not true, AFAIK that constraint was the main issue with getting Docker moved over to cgroupsv2. (Edit: some background here https://github.com/opencontainers/runc/pull/2113 https://github.com/opencontainers/runc/pull/2113) It's fixed now though so everything should work fine with systemd. If you aren't using cgroups and namespaces then you probably don't get much benefit from running a system like NixOS on bare metal either, so I'm having trouble figuring out what your use case would be. Any other immutable Linux setup will do, it might even be less hassle. Those other things you mention are confusing to me, gvisor and KVM are mostly orthogonal to container management. And FreeBSD jails don't work on Linux.
steve-chavez 5y ago
Not yet AFAICT. I've been following the nix-processmgmt[1] project, which looks it could make NixOS independent of the init system. [1]: https://github.com/svanderburg/nix-processmgmt https://github.com/svanderburg/nix-processmgmt
- mrobot 5y ago
  This is great, thank you. I was gonna start on something like this myself, glad i did not duplicate effort with it yet.
Ericson2314 5y ago
I haven't bothered to have a beef with systemd, but some of us have discussed https://github.com/InitWare/InitWare https://github.com/InitWare/InitWare to support non-Linux kernels. That would be really fun.
jeppesen-io 5y ago
Just take the time to learn systemd. Once you do, like nix, it saves so much time
- gigatexal 5y ago
  Yeah no point in fighting it. It’s the standard. Learn to love SystemD.
- rollcat 5y ago
  systemd is so complex, I've come to a conclusion, that it no longer fits my definition of free software. We allow runaway complexity to obscure the inner workings of an important software package, to the point, where having source access no longer makes a practical difference to a "casual" power-user or even a software engineer. I can source-dive runit, s6, OpenBSD's rc, or OpenRC and within a weekend, have a pretty OK understanding, fix a bug, or add a feature. Having software as complex as systemd taking so many roles, and making itself so ubiquitous and irreplaceable, makes me feel that I no longer have any control or understanding of my system, bugs or misfeatures just become things you live with, or you riddle yourself with arcane workarounds. Portability suffers, monoculture takes root. I've lost faith in "mainstream" Linux distros. I use macOS and OpenBSD for workstations, and Alpine where I need e.g. Docker. It must either be simple enough to understand, or provide enough utility/convenience that the lack of (practical) source access is compensated. systemd fits neither category.
  - candiddevmike 5y ago
    Yes, systemd has a ton of surface area and options. Yes, the man pages are long. No, you don't need to read them--the beauty of systemd is you control how much of the complexity you use. Unit files can be 10 lines or 30. Most of the extra options are for security and hardening, when you need them you'll be glad they're easy to turn on. For the other components, I think have a stable, familiar, and consistent set of core services (boot, ntp, logging, networking) is glorious
  - viraptor 5y ago
    Have you actually tried to dive into the part you're interested in? Where did you find the complexity? I've done it a few times for different components and found them pretty well separated and the source pretty straightforward. I have other issues with them, but complexity/obscurity of the is was not one of them.
mindslight 5y ago
NixOS is based on systemd. But it also seems like NixOS would be a great foundation to use something besides systemd. It would take some work of course, but it feels like you'd be mostly working with the OS rather than fighting it. However having used it, NixOS seems like it mitigates the worst aspects of systemd. It gets rid of that that /etc/systemd /lib/systemd symlink "cleverness" for overriding/enabling units. Being functional makes it so that when systemd mysteriously breaks - for example if there is a loop in dependencies - it's easy to track down the change that caused it. And rather than splaying the config out in a bunch of random "unit" files, it's all contained in the nix config. About the worst thing I can say is that defining your own service is a bit more obtuse that it needs to be, with the arbitrary terms of the systemd unit format carrying over into the Nix config.
- md8z 5y ago
  The symlinking is one of the things systemd actually gets right on traditional distros. The files in /usr/lib are immutable data files shipped by the packages that you're not supposed to edit. The symlinks to them in /etc are configuration that you can change.
  - mindslight 5y ago
    I get the rationale. it just makes for one more layer of indirection that you have to overcome when trying to figure out what the configuration actually looks like.
    - 5e92cb50239222b 5y ago
      Why would you do this manually? You also have to remember to check multiple configuration paths (e.g. override units), all of which can have an additional `.d` include directory. This is the price you pay for the flexibility systemd provides (and I argue it's much better than random System V-style shell scripts that can include anything at all, maybe even some remote scripts piped from curl to sh if developers was mad enough). Just use `systemctl cat`, it prints the whole effective configuration.
ayushnix 5y ago
I doubt GuixSD would work on most modern hardware considering it uses the Linux-libre kernel. Using the Guix package manager itself sounds useful though.
- rekado 5y ago
  Guix System works fine on modern hardware. I've been using it on new servers for the build farm at ci.guix.gnu.org and on laptops. Linux-libre has not been a problem. The biggest recurring issue is with graphic cards that have poor support in Linux and require firmware blobs and with WiFi cards that have no free drivers / firmware. It is trivial to use vanilla Linux with these machines as Guix System lets you use any other package for the `kernel` field in the configuration. The "nonguix" channel (hosted on Github) provides packages for vanilla Linux ("linux") in various versions, and also includes firmware packages that you can use in your config file. If that's the only thing keeping you from using Guix System then I'm happy to say that it's a hurdle that is very easy to overcome.
  - ayushnix 5y ago
    > The biggest recurring issue is with graphic cards that have poor support in Linux and require firmware blobs and with WiFi cards that have no free drivers / firmware. Intel, AMD, and Nvidia GPUS - all of them need firmware blobs to work as expected. Intel and AMD offer free drivers but not free firmware. And if you want to WiFi 5 (ac) or WiFi 6 (ax), chances are that you'll need non-free drivers/firmware as well. > The "nonguix" channel (hosted on Github) provides packages for vanilla Linux ("linux") in various versions, and also includes firmware packages that you can use in your config file. Ah, that's good to know. I'll probably give the Guix package manager a shot some day.

Can you do NixOS without systemd? If not, I'd look elsewhere for the distro. Maybe Guix?

xyzzyz 5y ago

What would you prefer to have in Nix instead of systemd?

NewJazz 5y ago
I've been running Upstart (well, a fork I maintain) for over 2 years on my laptops and SBC. I'd like to use that. TBH I think NixOS might make it easier than other distros to run a custom init. I just haven't gotten around to importing my configs into a nix derivation.
- md8z 5y ago
  If you have a parser for systemd unit files then you might have a chance to get that to work. If the whole reason you're doing it is to migrate back to upstart's syntax then it seems that would be not so useful, you might as well go in the other direction: write an upstart generator for systemd, and then you can just plug that into ordinary NixOS. Edit: Actually I think at some point NixOS did support upstart? Not sure whatever happened to that.
  - deleted 5y ago
    [deleted]
  - NewJazz 5y ago
    I'm not planning on working on anything related to systemd in the near future. If anything, I will write a config generator/type spec for startup/Upstart in Nix.
    - md8z 5y ago
      Unfortunately I think you probably will have to work on it if you want to not break existing configurations, so maybe NixOS is not for you. You could try alpine possibly? But with that you will have to do the same with init.d, so it's going to be somewhat of an uphill battle either way I guess. This is generally why I would discourage maintaining a service manager outside of an established distro, I tried to do it for about the same amount of time as you and it became not worth it. Upstart in particular has been basically entirely replaced by systemd.
      - NewJazz 5y ago
        I already use upstart on void no problem. Alpine would be a similar deal with me just managing the configs as raw text files via rsync. In fact my fork is already packaged in Alpine. A few people use it as a session manager for sway. There is no chance that my Nix changes would affect existing configurations. They would be completely self contained.
        md8z 5y ago
        I mean if you want to run existing configurations on your setup. Those aren't going to work. You can just install Nix on void though. I had some users too but it still wasn't really worth it. I can't suggest it as a business model or a hobby project, you are basically going to be highly constrained by everything else on the system and your setup will just start looking like everything else eventually. Systemd also works fine as a session manager for whatever.
        deleted 5y ago
        [deleted]
josephcsible 5y ago
Literally any other init system. Maybe OpenRC, runit, or upstart? I'd even prefer to be stuck with sysvinit forever instead.
b9be520d93286 5y ago
I would prefer OpenRC, runit or something similar.
- md8z 5y ago
  Those would probably be not so great matches for NixOS because they don't support the container stuff that systemd does, you would be throwing all that out.
  - NewJazz 5y ago
    Some people don't care. Some people want their boot ordering software and container runtime software to live in different code bases.
    - md8z 5y ago
      With cgroupsv2 there seems to be very little benefit to doing that since the container runtime needs to sit at the top of the process tree anyway, so I'm not sure I understand what the purpose of that would be or why you would want that. If you were using containers to run services then I can't really think of a situation where you wouldn't also want it as part of the boot ordering process, so your services will just have it working immediately upon boot.
      - NewJazz 5y ago
        That is not true at all about cgroup2. Also think outside the box. Not everyone is using cgroups and namespaces. Some people are out there using gvisor, or KVM, or FreeBSD jails.
        md8z 5y ago
        I'm not sure what you mean it's not true, AFAIK that constraint was the main issue with getting Docker moved over to cgroupsv2. (Edit: some background here https://github.com/opencontainers/runc/pull/2113 https://github.com/opencontainers/runc/pull/2113) It's fixed now though so everything should work fine with systemd. If you aren't using cgroups and namespaces then you probably don't get much benefit from running a system like NixOS on bare metal either, so I'm having trouble figuring out what your use case would be. Any other immutable Linux setup will do, it might even be less hassle. Those other things you mention are confusing to me, gvisor and KVM are mostly orthogonal to container management. And FreeBSD jails don't work on Linux.

steve-chavez 5y ago

Not yet AFAICT. I've been following the nix-processmgmt[1] project, which looks it could make NixOS independent of the init system. [1]: https://github.com/svanderburg/nix-processmgmt https://github.com/svanderburg/nix-processmgmt

mrobot 5y ago
This is great, thank you. I was gonna start on something like this myself, glad i did not duplicate effort with it yet.

Ericson2314 5y ago

I haven't bothered to have a beef with systemd, but some of us have discussed https://github.com/InitWare/InitWare https://github.com/InitWare/InitWare to support non-Linux kernels. That would be really fun.

jeppesen-io 5y ago

Just take the time to learn systemd. Once you do, like nix, it saves so much time

gigatexal 5y ago
Yeah no point in fighting it. It’s the standard. Learn to love SystemD.
rollcat 5y ago
systemd is so complex, I've come to a conclusion, that it no longer fits my definition of free software. We allow runaway complexity to obscure the inner workings of an important software package, to the point, where having source access no longer makes a practical difference to a "casual" power-user or even a software engineer. I can source-dive runit, s6, OpenBSD's rc, or OpenRC and within a weekend, have a pretty OK understanding, fix a bug, or add a feature. Having software as complex as systemd taking so many roles, and making itself so ubiquitous and irreplaceable, makes me feel that I no longer have any control or understanding of my system, bugs or misfeatures just become things you live with, or you riddle yourself with arcane workarounds. Portability suffers, monoculture takes root. I've lost faith in "mainstream" Linux distros. I use macOS and OpenBSD for workstations, and Alpine where I need e.g. Docker. It must either be simple enough to understand, or provide enough utility/convenience that the lack of (practical) source access is compensated. systemd fits neither category.
- candiddevmike 5y ago
  Yes, systemd has a ton of surface area and options. Yes, the man pages are long. No, you don't need to read them--the beauty of systemd is you control how much of the complexity you use. Unit files can be 10 lines or 30. Most of the extra options are for security and hardening, when you need them you'll be glad they're easy to turn on. For the other components, I think have a stable, familiar, and consistent set of core services (boot, ntp, logging, networking) is glorious
- viraptor 5y ago
  Have you actually tried to dive into the part you're interested in? Where did you find the complexity? I've done it a few times for different components and found them pretty well separated and the source pretty straightforward. I have other issues with them, but complexity/obscurity of the is was not one of them.

mindslight 5y ago

NixOS is based on systemd. But it also seems like NixOS would be a great foundation to use something besides systemd. It would take some work of course, but it feels like you'd be mostly working with the OS rather than fighting it. However having used it, NixOS seems like it mitigates the worst aspects of systemd. It gets rid of that that /etc/systemd /lib/systemd symlink "cleverness" for overriding/enabling units. Being functional makes it so that when systemd mysteriously breaks - for example if there is a loop in dependencies - it's easy to track down the change that caused it. And rather than splaying the config out in a bunch of random "unit" files, it's all contained in the nix config. About the worst thing I can say is that defining your own service is a bit more obtuse that it needs to be, with the arbitrary terms of the systemd unit format carrying over into the Nix config.

md8z 5y ago
The symlinking is one of the things systemd actually gets right on traditional distros. The files in /usr/lib are immutable data files shipped by the packages that you're not supposed to edit. The symlinks to them in /etc are configuration that you can change.
- mindslight 5y ago
  I get the rationale. it just makes for one more layer of indirection that you have to overcome when trying to figure out what the configuration actually looks like.
  - 5e92cb50239222b 5y ago
    Why would you do this manually? You also have to remember to check multiple configuration paths (e.g. override units), all of which can have an additional `.d` include directory. This is the price you pay for the flexibility systemd provides (and I argue it's much better than random System V-style shell scripts that can include anything at all, maybe even some remote scripts piped from curl to sh if developers was mad enough). Just use `systemctl cat`, it prints the whole effective configuration.

ayushnix 5y ago

I doubt GuixSD would work on most modern hardware considering it uses the Linux-libre kernel. Using the Guix package manager itself sounds useful though.

rekado 5y ago
Guix System works fine on modern hardware. I've been using it on new servers for the build farm at ci.guix.gnu.org and on laptops. Linux-libre has not been a problem. The biggest recurring issue is with graphic cards that have poor support in Linux and require firmware blobs and with WiFi cards that have no free drivers / firmware. It is trivial to use vanilla Linux with these machines as Guix System lets you use any other package for the `kernel` field in the configuration. The "nonguix" channel (hosted on Github) provides packages for vanilla Linux ("linux") in various versions, and also includes firmware packages that you can use in your config file. If that's the only thing keeping you from using Guix System then I'm happy to say that it's a hurdle that is very easy to overcome.
- ayushnix 5y ago
  > The biggest recurring issue is with graphic cards that have poor support in Linux and require firmware blobs and with WiFi cards that have no free drivers / firmware. Intel, AMD, and Nvidia GPUS - all of them need firmware blobs to work as expected. Intel and AMD offer free drivers but not free firmware. And if you want to WiFi 5 (ac) or WiFi 6 (ax), chances are that you'll need non-free drivers/firmware as well. > The "nonguix" channel (hosted on Github) provides packages for vanilla Linux ("linux") in various versions, and also includes firmware packages that you can use in your config file. Ah, that's good to know. I'll probably give the Guix package manager a shot some day.