On 22/08/2014 17:28, Nicolas Pierron wrote: > I am just saying, that I do not see why we could not use the jobs > syntax on top of a string-dependency system which is used by the > activation script. Systemd solves job dependencies dynamically to > benefit from the kernel scheduling, while the activation scripts are > concatenated ahead to make a single & simple activation process. I > think there is no need to ""always"" bring the complexity of systemd > to the init process, this could be optional. What I suggest is to have > a 2 backends for the init process. The systemd one, and the > string-dependency one. Of course, the string-dependency backend would > have to assert (while building the system) about cases which cannot be > handled. So you want to parse systemd nixos modules in a restricted mode and concatenate them? Yes, that makes sense. However, I'm not sure whether that's less work than adding systemd to initrd or it ends up with extra complexity and hidden bugs in the translation. Additionally, once systemd is started, it's not stopped and then restarted after switching root. It will be reloaded.
So it's correct that the complex dependency resolution of systemd is overkill, it's also true that systemd is a component that will be started anyway at some point. _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev