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