While this would probably break modular services, an idea I had was to have a high-level service configuration format in Nix that would eventually generate a service file for each init system.
Very difficult. Youād have to abandon and rewrite quite large portions of the nixos module code to actually get away from systemd. There have been efforts to essentially make a fork of nixos that works on another init system, but to my knowledge, none of them come anywhere close to the day-to-day usability of nixos.
This is in the āwould be nice to have, but takes more work than anybody has been willing to put into itā category.
If youāre interested in this, I think your best bet would be to look into the currently-in-development āmodular servicesā ( NixOS Manual ). I havenāt used them, but AFAICT in theory that would allow you to move āmostā(?) of the logic from the NixOS module to the nixpkgs modular service, and then build an alternative to NixOS that doesnāt use the NixOS modules but uses these modular services instead.
This looks promising, although I wonder if user services should be delegated to home-manager.
If all of the services.<insert thing here> could be migrated over to modular services, I feel like this whole init-freedom thing could become a lot more feasible.
An issue I do see, however, (not related to modular services) is having to port the Stage 1 boot over to all of the init systems. Since NixOS no longer uses the shell script-based stage 1, weād have to move stage 1 over to every init system supported, or force boot.initrd.systemd.enable = false for users whose initsystem != systemd, and fall back to the old stage 1
I think the idea is exactly that you could have a āmodular serviceā for something and then home-manager could leverage that and add any missing bits for running it as a user service.
I think thatās the idea, yeah.
I think NixOS should stick to systemd, and any alternative would live āoutsideā of NixOS, bring its own stage 1, but potentially leverage modular services from nixpkgs.
(I havenāt used modular services yet so I donāt have an opinion on whether theyāll be good/successful, just pointing you at things that might be interesting to you and how I understand them)
[quote=ātejing, post:2, topic:78333ā]
none of them come anywhere close to the day-to-day usability of nixos.
[/quote]
i guess it depends how you define āusabilityā, but i strongly disagree with that statement, so much that i would invite you to try finix on a spare device you might have.
personally i run finix on my laptop, spare laptop, home server, htpc, vps, and steam deck and find it just as usable as nixos in most cases. so please give finix a try to see if your opinion is supported by the reality of the situation if youāre up for it
Itās true that I donāt have a good grasp of the usability of finix, but at the least, as I understand it, you lose most of the ready-made modules for various functionality that nixos would have. Simply because nowhere near as much integration effort has gone into finix.
Thatās still a significant reduction in āday-to-day usabilityā, even if itās at the level where a more experienced nixer could fill those gaps themselves as needed. For a more average nixos user, itās a major issue, and I wouldnāt feel right pretending that itās ready for just anyone to switch over to.
I am very interested in what becomes of finix, though, and I hope it might even develop into a more generalized abstraction over the init system at some point.
I have considered Finix and do want to switch to it at some point, but many of the āservices.*ā things that I require donāt exist on Finix. I might spend an afternoon writing some services I use for Finix and contribute them, when i have time.
The amount of work required to untangle NixOS makes it politically infeasible.
For an s6-based system there is the original nixos-init-freedom and SLAM which is a fork of Finix with an init system abstraction and that leans harder into modular-services.
The problems are overstated for the case where a competent Nix user wants to run it on their own devices; for large-scale deployment with uneven user competence itās more complicated.
Stage1 complexity comes from supporting many combinations of setups; taking a stage1 from finix and maybe adding one feature you miss, or even writing a full stage1 from scratch for the five systems you run is pretty simple. (I run my own stage1)
As stage1 complexity comes from the number of combinations, supporting better init systems is politically infeasible (because this increases complexity quite a lot). For services, though, the valuable part is config file generation and sometimes command-line options, which might eventually be shareable between different setups is modular services get used a bit more.
Note that modular services are mostly just a cleanup of what part of code does what, it does not meaningfully restrict what is done for systemd service files, so basically no one has sufficient stake to stop this; actual minor breakage cases have not previously slowed down code uniformisation efforts (except just enough to fix the specific breakage observed), so the precedents point towards this going through.
If the module systems abstraction actually grows beyond the current minimal scope, Iām worried that we just end with very poorly defined semantics for the various options. Right now you can easily learn about the semantics of the systemd.service module by looking up the option in the systemd documentation because the option names = the systemd config keys. In future will I have go digging through the system.service module everytime I want to learn what the options do, possibly in addition to docs for multiple init systems, because the options just map to whatever comes closest in the target init system? It wouldnāt surprise me.
I agree. I am in the opposite camp as I think systemd and Nix complements each other very well. I canāt imagine a more convenient way to configure systemd than using NixOS.
Unfeasible. Systemd brings so much to table that is well integrated within systemd that you would need to rebuild large parts of that to only reach parity and what do we gain at this point? More freedom to do everything we want ourselves, but we have to do everything ourselves!
We would also lose compatibility with many other major distros and some upstream work.
For modular service: I wouldnāt want any module I maintain to be part in that experiment just because I cannot guarantee that things would work equally and I do not want and largely also canāt allocate time to also maintain them or help with bugs.
IMO splitting the community in init systems will make support a lot harder and debugging things more demanding. I think it would require me to refuse support for anything other than systemd to not lose interest in the project or even get burned out.
As far as I understand, the idea of a modular init system, like what could be done with modular services, wouldnāt require individual package/service maintainers to keep up with internals of that abstraction - besides an initial migration to modular services, most of the burden would be in the code for maintaining abstractions of the init services
As someone who has used alternatives to systemd in the past, the way all their services work are fairly similar, I believe this could be technically viable (maybe not politically, but thatās another can of worms). Thatās something Iād be interested to work on when I get more experience contributing to Nix.
Thatās really not true. Thereās a lot of different aspects of service management that differ quite a bit between service managers. For instance, systemdās concept of āunitsā is really unique because dependencies come in the form of both event propagation rules (Wants=, PartOf=, Triggers=, etc.) as well as job ordering queues (After=, Before=). The semantics of these things are very often critical to how the unit functions. For instance imagine a service that depends on a certain file system and should not listen on the network until the firewall starts. In systemd, you can just order a socket unit after the firewall unit, and you can have the socket unit trigger a service unit that depends on a mount unit. The socket isnāt listening until after the firewall is up, and a user connecting triggers an on-demand startup of the service, which queues jobs to mount the corresponding file system first after waiting for its block device to appear.
How would you do that with another service manager? Iām not saying you couldnāt; Iām just saying that with systemd every single behavior I just touched on is a property of a unit, whereas in other systems all of those things would be done completely differently. Iām sure that implementing this example is perfectly reasonable in your service manager of choice, but to say that the implementation would be fairly similar to how you do it with systemd is certainly not true. You would not be making things analogous to systemd units with properties analogous to systemd unit properties. macOSās launchd, for instance, basically only has the socket-activated part of that equation. Others are more similar and others still are more different. The point is that thereās a wide variety of ways different systems do these things.
And thatās just dependency management. Thereās all sorts of other massive differences. Bootup, UID allocation, sandboxing, runtime administration (e.g. the things switch-to-configuration does), device / driver management, and logging are all completely different depending on the service manager. Thereās all kinds of differences that majorly influence how you implement your use case on that service manager.
I have become very convinced that you cannot make an abstraction layer for portability between service managers without that layer being so large and complicated as to constitute a service manager itself; it would just be a custom service manager implemented in terms of other service managers.
