Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
Let me comment: - Is systemd a step backwards? * upstart didn't even implement logging, did it? * some more things I think systemd does better than upstart (eg socket activation) However I agree that journalctl is horribly slow. - Must the module system or systemd go away? I don't think so. why not add a new option services.my_modular_thing = mysql postgres bitlbee ..; But what is the goal? domain_1 = foreign_domain www.example.com; domain_2 = domain_managed_by_X www.foo.bar; ssl_cert = yyy; php_app = new wordpress_instance { databases = [ { type: mysql; timeouts: foobar; require_mysql_import_in_path = true } ]; http = [ { domains = [domain_1 domain_2]; port = 8080; } { domains = [domain_1 domain_2]; port = 443; inherit ssl_cert; } ]; } container_1_amazon_eu = { apps = [ php_app ]; } container_2_load_balancer_with_instances { apps = []; } realise [container_1_amazon_eu container_2_load_balancer_with_instances ]; But still, how to move the app from container_1_amazon_eu to container_2_load_balancer_with_instances ? Then due to TTL in DNS there is much more to take into account such as HTTP proxies, mysql replication (if you want minimal down times) and whatnot. Thus a php_app.move_to_container_with_minimal_downtime(container_2_load_balancer_with_instances) can this be done with a configuration file at all? what should move_to_container_with_minimal_downtime ideally do? 1) prepare the second container (create user account, database) 2) start mysql replacation (eg lock database in container 1, create btrfs snapshot, read replacation state, unlock, copy btrfs backup to container_2_load_balancer_with_instances, start replication, wait till its in sync) 3) stop web app @ container_1_amazon_eu, setup http proxy to new IP, 4) garbage collect (thus delete all account/database stuff @ container_1_amazon_eu) How can this be expressed using a simple text file ? Some things just require global state IMHO .. So what do we really want ? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
On Sun, Dec 28, 2014 at 11:11 PM, Ertugrul Söylemez ert...@gmx.de wrote: Hi Colin, This sounds a lot like Disnix! How would it be similar? How would it be different? Disnix and NixOps are machine-oriented. You have a network of machines with configurations. The goal is a service-oriented architecture. Every service itself is a machine, and those machines can be combined to larger machines. Yeah, that's certainly true of Nixops. My understanding of Disnix, though, is that it let's you describe, separately, services in the abstract, machines available for running them, and the deployment of abstract services onto the physical machines. Disnix seems to be dead, though, so even if what you're proposing is very similar, it would be a big improvement on the current state of the art. -Colin ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd
Ertugrul Söylemez ert...@gmx.de skribis: I would prefer and do propose an algebraic solution (view services as a toolbox from which you can pick the services you want and compose them together). A services configuration then might look like this: services = bitlbee { port = 1; stateDir = /var/lib/bitlbee1; } bitlbee { port = 10001; stateDir = /var/lib/bitlbee2; } nginx { httpConfig = ...; } postfix { postMasterAlias = blah; } The big difference is that now services are first class values and form a monoid under composition, which brings a number of advantages: FWIW, Guix uses an approach along these lines: the ‘bitlbee-service’ function, for instance, returns a ‘service’ object as a monadic value (see http://www.gnu.org/software/guix/manual/guix.html#Defining-Services for details.) Unlike in NixOS, the service implementation doesn’t have access to the rest of the system configuration, which I think is a good thing, as you note. What’s unsatisfying (and thus subject to change) is that ‘operating-system’ objects (which are pure declarations) end up with monadic values in their ‘services’ field. That makes it inconvenient to, say, filter items from that list, or to tweak their configuration, because one first needs to bind them. That said, it’s probably not a problem for Nix, because every Nix function is really a function in what we call the “store monad”. In your example, what would ‘bitlbee’, ‘nginx’ etc. return exactly? An attribute set describing the service? Anyway, I’m interested in following this discussion. Thanks, Ludo’. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
Hi Alexander, We can use a monoid system to construct configurations, but the socket activation standard for example, is centered on optimizing the activation script itself. What are your thoughts on the activation script? I have no concrete thoughts at this point, just throwing around ideas. Socket activation, for those daemons that support it, should be something sufficiently transparent from the point of view of the configuration author. I can easily see that using systemd might be overkill and way too complex for a container-based system, so I think there is something to research here. The trouble with systemd for this particular purpose is that it wants everything to have an identity, so basically you need to map a compositional system to a system of global variables. In many ways you go through the same trouble when compiling a functional language to an imperative architecture. I also think upgrading services doesn't really seem to work in systemd or in the current setup. Similarly to how, when using a distributed docker setup, we have a load-balancer that atomically switches instances, we should not need to take down the old instance service before the new one is created. Rather, the upgraded service should be started in isolation (using containers), and after ensuring that it has started, is working etc, then should the switch happen using namespaces, routing entries etc. This should be the preferred way to deal with non-transactional services (i.e. non-database stuff). That's pretty much the way I want upgrading to work. The idea that the old service must be stopped before the new one is started is based on what I think is a conflation of concerns, namely treating the whole service state as global state. Yes, that's exactly what I want to get rid of. Ironically that's something systemd does very well. Systemd gets the stuff right that we don't want in the first place. =) Instead a lot of services can be treated as a sequence of isolated containers, and a small set of load-balanced, mutable service entry points. Namespace magic can make a lot of previously global state, local, such as ports, pid-files, log files etc. For these kinds of services, you don't need graceful shutdown, which is a great simplification, similarly to what docker typically provides. I feel that a great design in this area should blend well with distributing services across machines, failover, etc. which are concerns that systemd doesn't start to cover. That's a very good summary of why I want to implement my proposal. Let me see if I can get a working prototype. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd
Hi Ludovic, FWIW, Guix uses an approach along these lines: the ‘bitlbee-service’ function, for instance, returns a ‘service’ object as a monadic value (see http://www.gnu.org/software/guix/manual/guix.html#Defining-Services for details.) The way I understand the section on the store monad is that it's really a state monad with a view on the current store (they should really show the underlying types to make this easier to understand). That's not related to the way they define services, but rather just how the store itself is used. Nix has the store built into the language. Side effects happen to build store paths and, once built, they appear like regular immutable values within the language. It's convenient, but makes the assumption that build outputs depend solely on their inputs, which unfortunately, as we know, is not always true at this point. However, the way they define services seems indeed a lot better than what we currently have. In part they already have what I think we should have (functional services), but with no algebraic structure behind it other than the store monad. Unlike in NixOS, the service implementation doesn’t have access to the rest of the system configuration, which I think is a good thing, as you note. Absolutely. Everything they depend on should be an argument. What’s unsatisfying (and thus subject to change) is that ‘operating-system’ objects (which are pure declarations) end up with monadic values in their ‘services’ field. That makes it inconvenient to, say, filter items from that list, or to tweak their configuration, because one first needs to bind them. That said, it’s probably not a problem for Nix, because every Nix function is really a function in what we call the “store monad”. You could think of it that way, if you wanted. I prefer to think of what Nix does as the same magic that functional languages do with other resources like memory (alloc and GC). In your example, what would ‘bitlbee’, ‘nginx’ etc. return exactly? An attribute set describing the service? As a first approximation there would be a Service monoid, which would combine certain typical attributes about a service, including startup scripts, required bind-mounts, required system resources and if really necessary shutdown scripts (most programs should shutdown properly when the container goes down). Service : Mon Its identity idS would be the empty service, which you can think of as an empty group of processes with no mounts, no resources, etc. The Bitlbee service would be constructed through a regular function that takes the typical bitlbee options. Nothing special here: bitlbee : BitlbeeConf - Service The nginx function is more interesting. It involves a second monoid, the monoid of web services (identity idW): WebService : Mon Then nginx is a monoid morphism, nginx : WebService - Service that is a function with additional structure, in particular: nginx x ◇ nginx y ≡ nginx (x ◇ y) nginx idW ≡ idS The most important part is to get the equivalence `≡` relation right, i.e. when do we regard two services as equivalent? This requires a lot of careful thought, because services in the real world are messy and effectful. Example: 1. One nginx instance serves two websites x and y. 2. Load balancer scenario: Three nginx instances. One serves x, one serves y, the other redirects to the correct instance depending on the request. 3. Mapping identities: A hundred load-balanced nginx instances, one of them serving x, a second one serving y and all others serving nothing at all (returning 404 unconditionally). These three examples really describe the same service. One may be a more efficient implementation, but they should be equivalent with respect to `≡`, because they are indistinguishable from the outside other than in exceptional cases (case 3 is more likely to run out of memory than case 1). That enables us to use equational reasoning for correctness. It also enables us to apply automatic semantics-preserving optimisations. Example: The host may be serving two sites. At the same time a system monitoring daemon might generate health reports periodically that are also served via HTTP. Such a configuration might look like: nginxStatic site1.host /var/www/site1 nginxStatic site2.host /var/www/site2 systemHealth health.host A semantics-preserving optimistation (which is really not an optimistation, but the way web services are combined) would collapse all of that to a single instance of nginx and one entry in the crontab for the health reporter. I hope this gives a first impression of how everything would fit together. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
On Sun, Dec 28, 2014 at 11:13 AM, Ertugrul Söylemez ert...@gmx.de wrote: Instead a lot of services can be treated as a sequence of isolated containers, and a small set of load-balanced, mutable service entry points. Namespace magic can make a lot of previously global state, local, such as ports, pid-files, log files etc. For these kinds of services, you don't need graceful shutdown, which is a great simplification, similarly to what docker typically provides. I feel that a great design in this area should blend well with distributing services across machines, failover, etc. which are concerns that systemd doesn't start to cover. That's a very good summary of why I want to implement my proposal. Let me see if I can get a working prototype. This sounds a lot like Disnix! How would it be similar? How would it be different? -Colin ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
Hi Colin, This sounds a lot like Disnix! How would it be similar? How would it be different? Disnix and NixOps are machine-oriented. You have a network of machines with configurations. The goal is a service-oriented architecture. Every service itself is a machine, and those machines can be combined to larger machines. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
Yay! The idea is even better than I expected! 2014-12-27 4:48 GMT-02:00 Ertugrul Söylemez ert...@gmx.de: Note that systemd is not just an init system. This is my first problem - systemd is a bit bloated and mysterious. I don't like the idea of big blobs doing everything on a system. It becomes harder to maintain and modify, and even to modularize. But, modifyng the way we treat about services and modules is revolutionary! It is just like Nix is for package management, applied to system maintainance :) 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. =) Let me know what you think. If this idea finds acceptance, I'm happy to develop a formal model and a prototype. Well, we need also to do it in a way we won't be handcuffed by a particular init/supervisor implementation. We can even to switch the supervisor/init without worries about a complete rewriting of services. There is some I am searching about: * http://www.gentoo.org/proj/en/base/openrc/ * http://supervisord.org/ * http://uselessd.darknedgy.net/ * http://skarnet.org/software/s6/ Some comparisons: * http://wiki.gentoo.org/wiki/Comparison_of_init_systems * https://lwn.net/Articles/578209/ * https://lwn.net/Articles/578210/ I am not even a junior-seasoned programmer, not even on functional paradigm, but I wanna help. Greets, Ertugrul Greets! Anderson ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
On Sat, Dec 27, 2014 at 7:48 AM, Ertugrul Söylemez ert...@gmx.de wrote: I think as a first step to get rid of systemd and gain a much more sensible services model as well we should move away from NixOS modules for services. The module system is made in such a way that one can build on top of the work of the other without having any computer scientist knowledge. This is also the reason why I am pushing to abolish functions as option definitions. Most of the time if you want to use a function, you can express it as a set of input (option declaration) which are being processed to provide a lower level of abstraction given by another module (option definitions). The module system does not prevent us from doing anything, it provides a new way of formatting which makes things declarative and extensible. If a module does not serve what you expect, you can always write another module and use it instead of the previous one. Having multiple instances of a service is an issue with the module, not a limitation in the module system. Being able to reason about the resulting system is very important. Have you tried nixos-option ? I would prefer and do propose an algebraic solution (view services as a toolbox from which you can pick the services you want and compose them together). A services configuration then might look like this: services = bitlbee { port = 1; stateDir = /var/lib/bitlbee1; } bitlbee { port = 10001; stateDir = /var/lib/bitlbee2; } nginx { httpConfig = ...; } postfix { postMasterAlias = blah; } First, unamed instance are not modular. This is why we are moving away from types.listOf and that the suggested alternative is a backward compatible version named types.loaOf (list or attribute set of). Second, I see 2 additional concepts and I do not think I would be able to explain these to my grand-mother, Can you? I think what you are trying to express can be done with the module system, maybe you can try to make a prototype using the module system and a new top-level system-proto option which is declaring submodule for every service that you want to declare. Maybe we can learn something from this experiment, in order to better design future services. In any cases, I do not think we want to switch to something without having a working prototype to experiment with. Do not take that personally, this was also the case with the module system [1]. [1] http://comments.gmane.org/gmane.linux.distributions.nixos/1187 -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
Hi all, At Zalora, we are gradually switching to using defnix https://github.com/zalora/defnix. It is still very much under active development (read: may change at any time), and the underlying implementation does use systemd, but the service/functionality interface (check out the defnixos directory) are specifically designed to be init system agnostic. In particular, behaviors like socket activation, cron jobs, restart on failure, etc. are all managed via independent programs/library functions that don’t require any specific functionality from the init system. Eventually even “start a bunch of services” will be managed like that as well. ~Shea On Dec 27, 2014, at 6:48 AM, Ertugrul Söylemez ert...@gmx.de wrote: Hi there Anderson, I want to know if it's possible to use an alternate to Systemd as init system on NixOS. this has been asked many times now, and I'm in favour of switching to an alternative. Unfortunately it's not easy, because a considerable portion of NixOS currently depends on systemd, most notably the services infrastructure and pretty much all container-related stuff. Note that systemd is not just an init system. One thing most of us seem to agree about is that conceptually NixOS does not depend as much on something like systemd as most other distributions do. In principle most of what systemd does could be handled by the activation script and perhaps a custom daemon (or even just a set of scripts) that allows us to manage the services that are part of the current system derivation. NixOS can deal with things like cgroups or ACPI events in a more sensible, repeatable and transparent way. I would go as far as to say that systemd is the number one thing that cripples us in many ways. 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. Remember that immutability is not only about the filesystem. How to get rid of systemd = I think as a first step to get rid of systemd and gain a much more sensible services model as well we should move away from NixOS modules for services. At this point we are trapped in the traditional view that services preexist and we get to enable/disable them. Our system is defined by a large set of switches and global settings. This needlessly robs us of a lot of flexibility, for example to run multiple instances of the same daemon or to give us a choice to use our already running preferred webserver when installing a web application as a service. It also corrupts our ability to reason about the resulting system, because enabling a certain service might trigger settings in some other part of the system configuration to change. This has actually bitten me in the past. Being able to reason about the resulting system is very important. I would prefer and do propose an algebraic solution (view services as a toolbox from which you can pick the services you want and compose them together). A services configuration then might look like this: services = bitlbee { port = 1; stateDir = /var/lib/bitlbee1; } bitlbee { port = 10001; stateDir = /var/lib/bitlbee2; } nginx { httpConfig = ...; } postfix { postMasterAlias = blah; } The big difference is that now services are first class values and form a monoid under composition, which brings a number of advantages: * It allows us to run multiple instances of a daemon with slightly different configurations, as those are really just similar but otherwise unrelated services. * Services can take services as arguments, which would become the primary way to construct a dependency graph. Think of a web application depending on a webserver or the other way around. * We could develop a fully automated way for services in different containers to communicate with each other. * Now people like me can actually use equational reasoning to understand and make predictions about the resulting system. I can use the fact that the `` operator is associative, that certain services are idempotent with respect to `` and also that certain functions are morphisms in a rich category. For example if the nginx function is a monoid morphism, then I know that regardless of how I compose multiple webservers, the result will be a sensible combination of either separate daemons or multiple configurations. This would be extremely valuable. The last point is very important, because it basically tells that a service is not directly related to what programs will run on the resulting system. Even if you compose ten nginx services, there will be only one nginx *program* with a suitable configuration file to represent this composition. It also means that when a service itself comes with nginx, then adding
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
On 27 December 2014 at 07:48, Ertugrul Söylemez ert...@gmx.de wrote: 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. [...] 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. 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... How to get rid of systemd = Uh. 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. What's left of your argument then, besides I don't like the damn thing? You'll be writing your own daemon supervision code before you know it. With more bugs. Those who don't understand systemd are doomed to reinvent it. Poorly. :-) 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. Regards, T G-R ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
Hi Nicolas, I think as a first step to get rid of systemd and gain a much more sensible services model as well we should move away from NixOS modules for services. The module system is made in such a way that one can build on top of the work of the other without having any computer scientist knowledge. I hope you realise that my proposal makes everything *simpler* both for module/service writers and configuration authors. Services will be simpler and less tedious to write (simple functions). They will compose naturally. The algebraic part is *design* and perhaps terminology. It enables *those who want* to exploit the additional structure especially for equational reasoning and containerisation, but understanding abstract algebra is in no way a requirement for the regular NixOS user. Let me respond to your objection anyway: If we can have a configuration DSL that gives us a major benefit, including much simpler modules, provable safety, full automation of tedious tasks, etc., then I'm sorry for the I don't want to learn something new cavemen, but I'm more than happy to leave them far behind. Exploring and using new ideas require acquiring new knowledge from time to time. NixOS itself is a great example of this. One thing I'd like to see *by default* in NixOS is containerisation, even for the regular desktop user who only uses Firefox and LibreOffice, in the spirit of Qubes OS. It's technically possible, supported by Linux by and does not require setup. This is the motivating purpose for my proposal. Let me give you a very compelling example: services = withBridge bridgeConfig (br: container (nginx ... openssh ...) container (openvpn ... br ...)) openssh ... This simple configuration would define a whole network of containerised applications. This is also the reason why I am pushing to abolish functions as option definitions. Most of the time if you want to use a function, you can express it as a set of input (option declaration) which are being processed to provide a lower level of abstraction given by another module (option definitions). Perhaps NixOS with its *functional* package management and *functional* configuration language is just the wrong distribution for you. ;) /joke Jokes aside, when a function makes sense, I go for it, because functions make things simpler. Please stop pushing that way. For those who aren't programmers, functions are just syntax anyway. The module system does not prevent us from doing anything, it provides a new way of formatting which makes things declarative and extensible. I won't go as far as to argue that declarative is a meaningless term. Also I'm not sure what you mean by formatting (syntax?). The extensibility of the current module system is limited in the same way global variables limit the extensibility of a program. Everything is global, and every module can affect every other module in completely unrestricted and unpredictable ways. Any kind of data feedback requires something you would classify as computer scientist knowledge (least-defined fixed points of nonstrict recursive functions). Again, this has bitten me in the past. There is no way to reason about your configuration other than to look into the resulting derivation. This is a bad situation. The more modules and options we get, the more difficult it will get to keep everything together. If a module does not serve what you expect, you can always write another module and use it instead of the previous one. Having multiple instances of a service is an issue with the module, not a limitation in the module system. I guess we have very different philosophical views, so it is difficult to communicate the advantage of my proposal to you without actually implementing a prototype. I admit that to a non-FP programmer the concept I propose must look very similar to what we have today except that you can add the same service multiple times. The advantage is only apparent when you start ot use the functional and algebraic features. Otherwise all that changes is that the syntax becomes simpler (still a small benefit though). Being able to reason about the resulting system is very important. Have you tried nixos-option ? This question suggests that you are unfamiliar with equational reasoning. To answer your question: Yes, I'm aware of nixos-option, and it's orthogonal to the issue I'm raising. Also I should point out explicitly that I'm not proposing to replace the module system. I'm proposing not to use the module system for services. If my proposal works as intended and finds acceptance we will quickly find other things that would benefit from this, for example the network configuration. I would prefer and do propose an algebraic solution (view services as a toolbox from which you can pick the services you want and compose them together). A services configuration then might look like this:
Re: [Nix-dev] How to get rid of systemd (was: Modifying the initsystem (introducing S6 supervision suite))
Hi Michael, Well, with NixPkgs having multiple instances of a package installed requires zero support from the package expression itself. I do think that services becoming more like packages would be a good thing, but currently I have no idea how to do this except by just giving up the module system. I don't think we need to or even should give up the module system. Some settings are global (like the hostname and most boot options), and the module system makes those a lot easier to manage. This proposal is only for services and service-like entities. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
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
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
I'll just jump in and say that if you is going to donate time to do this, Ertugrul, then I'm all for it. It seems like it is possible to make the service system a lot leaner, smaller, and nicer. This is especially true when services are in containers, or NixOS is used in docker containers. For those that don't really get what Ertugrul describes, looking at what is called orchestration systems for docker gives a sense of what I think he is talking about. An orchestration system is a way of defining how multiple docker containers are connected to each other. The orchestration system itself doesn't necessarily need to keep the state of the system, because the cloud system it operates on can just spin up new instances, or the cloud system has a service discovery mechanism, or which service is active is handled by a load balancer. Similarly, on a host, when we have cgroups/containers/namespaces, we can spin up a new service in a container and redirect traffic to it by fiddling with namespaces, routing settings etc. We can make I am mostly interested in seeing how the monoid On Sat, Dec 27, 2014 at 6:53 PM, Ertugrul Söylemez ert...@gmx.de wrote: 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. We can use a monoid system to construct configurations, but the socket activation standard for example, is centered on optimizing the activation script itself. What are your thoughts on the activation script? I can easily see that using systemd might be overkill and way too complex for a container-based system, so I think there is something to research here. I also think upgrading services doesn't really seem to work in systemd or in the current setup. Similarly to how, when using a distributed docker setup, we have a load-balancer that atomically switches instances, we should not need to take down the old instance service before the new one is created. Rather, the upgraded service should be started in isolation (using containers), and after ensuring that it has started, is working etc, then should the switch happen using namespaces, routing entries etc. This should be the preferred way to deal with non-transactional services (i.e. non-database stuff). The idea that the old service must be stopped before the new one is started is based on what I think is a conflation of concerns, namely treating the whole service state as global state. Instead a lot of services can be treated as a sequence of isolated containers, and a small set of load-balanced, mutable service entry
[Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
Hi there Anderson, I want to know if it's possible to use an alternate to Systemd as init system on NixOS. this has been asked many times now, and I'm in favour of switching to an alternative. Unfortunately it's not easy, because a considerable portion of NixOS currently depends on systemd, most notably the services infrastructure and pretty much all container-related stuff. Note that systemd is not just an init system. One thing most of us seem to agree about is that conceptually NixOS does not depend as much on something like systemd as most other distributions do. In principle most of what systemd does could be handled by the activation script and perhaps a custom daemon (or even just a set of scripts) that allows us to manage the services that are part of the current system derivation. NixOS can deal with things like cgroups or ACPI events in a more sensible, repeatable and transparent way. I would go as far as to say that systemd is the number one thing that cripples us in many ways. 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. Remember that immutability is not only about the filesystem. How to get rid of systemd = I think as a first step to get rid of systemd and gain a much more sensible services model as well we should move away from NixOS modules for services. At this point we are trapped in the traditional view that services preexist and we get to enable/disable them. Our system is defined by a large set of switches and global settings. This needlessly robs us of a lot of flexibility, for example to run multiple instances of the same daemon or to give us a choice to use our already running preferred webserver when installing a web application as a service. It also corrupts our ability to reason about the resulting system, because enabling a certain service might trigger settings in some other part of the system configuration to change. This has actually bitten me in the past. Being able to reason about the resulting system is very important. I would prefer and do propose an algebraic solution (view services as a toolbox from which you can pick the services you want and compose them together). A services configuration then might look like this: services = bitlbee { port = 1; stateDir = /var/lib/bitlbee1; } bitlbee { port = 10001; stateDir = /var/lib/bitlbee2; } nginx { httpConfig = ...; } postfix { postMasterAlias = blah; } The big difference is that now services are first class values and form a monoid under composition, which brings a number of advantages: * It allows us to run multiple instances of a daemon with slightly different configurations, as those are really just similar but otherwise unrelated services. * Services can take services as arguments, which would become the primary way to construct a dependency graph. Think of a web application depending on a webserver or the other way around. * We could develop a fully automated way for services in different containers to communicate with each other. * Now people like me can actually use equational reasoning to understand and make predictions about the resulting system. I can use the fact that the `` operator is associative, that certain services are idempotent with respect to `` and also that certain functions are morphisms in a rich category. For example if the nginx function is a monoid morphism, then I know that regardless of how I compose multiple webservers, the result will be a sensible combination of either separate daemons or multiple configurations. This would be extremely valuable. The last point is very important, because it basically tells that a service is not directly related to what programs will run on the resulting system. Even if you compose ten nginx services, there will be only one nginx *program* with a suitable configuration file to represent this composition. It also means that when a service itself comes with nginx, then adding another nginx does not actually mean that two instances will be running. If we go as far as to containerise services by default, we can make predictions about the container's structure. 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. =) Let me know what you think. If this idea finds acceptance, I'm happy to develop a formal model and a prototype. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev