I also don't see these issues with journald (on non-SSD systems). I would like to add I absolutely love systemd, as it provides proper dependency management, helping immensely for more dynamic setups where hardware changes should trigger services reconfiguration, or for changing services/vpn/routing based on wifi access point and more. It's really nice that - when configured well - things just work, no matter if you're booting, restarting some service or switching to a new configuration. No more subtle timing errors or things that need manual restarts in edgy situations. Systemd's "state manager" is extremely capable. And extremely fast compared to oldschool linear scripts.
Also - althoughh nix abstracts over it - configuration through unit files is declarative and clean. Unifying things like daemonizing, run-as-other-user, run-in-chroot, apply capabilities and logging is brilliant compared to ambiguous scripting hacks. I really feel systemd is a perfect match for nixos. Nix manages state on disk, systemd manages runtime state. Both try to do this as deterministically as possible, though a declarative configuration. Sure there might be some operational bugs, but I would suggest turning them into issues, tracking them down and taking things up with upstream as they are probably not all that huge. The overall design seems very well thought-out and clean. If we ever want to move to some other init system, I think this will be easier than the upstart->systemd move. That move was mostly complicated by the fact that upstart just didn't have most config settings and abstractions, so stuff for run-as-user and daemonization logic was put into a bash script. That had to be extracted into attributes. If we move to something else, we now have nicely abstracted configurations for most services (although named systemd.services.* instead of something more generic), so exporting config files for anything (even upstart) based on these attributes is probably gonna be easy, making a "port" way simpler than before. Just my 2 cents :) Mathijs _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
