Hi there Tobias, >> One thing most of us seem to agree about [...] > > Maybe that's true (I don't see a consensus on the list, only the usual > sparse FUD. I don't follow IRC) but arguments that start this way > always give me the willies.
I understand why, but I'm not very good at English rhetoric. Please don't let that overshadow the rest of the mail. >> [...] is that conceptually NixOS does not depend as much on something >> like systemd as most other distributions do. > > "Something like systemd"? Nix doesn't magically make *nix less *nix, > for better or worse. The meat of systemd is still service management, > which NixOS needs as much as any distribution. NixOS needs service *management*, but it doesn't necessarily need a service *manager*. In traditional distributions services are managed by destructive update (enable/disable). Normally we don't have that. >> Switching to it was a huge step back from the ideals of NixOS, >> because it represents all the traditional views on what a system >> should look like: a giant pile of interconnected mutable variables. > > That's what a running system is, though. Immutability *is* just for > file systems. You plant a pretty tree, and hope it describes a sane > system that will do the right thing most of the time. Then, something > will happen that will kick all your pretty algebraic assumptions off > the table very quickly. Most of your OS is in buggy C, whether you > like it or not... The assumptions are not that the programs will do what I expect them to do, but rather that "two instances of nginx each with one virtual host" is equivalent "one instance of nginx with two virtual hosts". This does not assume anything about the correctness of nginx itself, but it does help building systems, containers and networks componentwise. > You seem to have some very nice ideas about describing "services" (or > something better), if still very rough around the edges. But if you > can't implement your ideas on top of systemd, so much for > init-agnosticism. And probably conceptual purity, too. This may be a misunderstanding. Init-agnosticism means that the complexity of translating this concept to an actual set of services that systemd can work with is the responsibility of a single function/script/whatever. We achieve separation of concerns. Should we, at any point, decide to turn our back on systemd or even just provide the option to use another manager, then all we need to do is to reimplement this one function/script/whatever. > Those who don't understand systemd are doomed to reinvent > it. Poorly. :-) I do understand systemd very well and still don't like it. However, reinventing it is certainly not something I have planned for the near future. =) >> As a final bonus this is so difficult and ugly to solve with systemd >> that we would feel a much greater temptation to get rid of it. =) > > Because your plan is centred entirely around it not being systemd. Not at all. It would be a nice bonus, but I doubt that it's going to happen. The motivation for my proposal, as the motivation for most of the things I do right now, is easy, composable, transparent containerisation as well as a configuration DSL that is easy to reason about. Greets, Ertugrul _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev