User: Danbst/Ideas in Limbo

NixOS unified lots of different people, by providing a new, pretty much declarative way to configure system. It spawned lots of ideas, some of which were implemented, but most did stagnate or reverted in opinionated fashion. Here's going to be the list of such ideas, like an overview of ideas not landed to NixOS.

Service Abstraction Layer (SAL)

Why should NixOS run "services" only via systemd? Or rather, why stick to one specific implementation for such an abstract thing as "service"? Can we use same service set for Linux and MacOS? Such questions drives lots of people to explore new abstraction primitives.

PR: One way to do other types of services by copumpkin

This abstraction tries to use same launcher script in systemd ExecStart, Docker container and as executable script. No attempt to generalize systemd service parameters

Make a service abstraction layer by copumpkin

This is driving issue for previous linked PR. It is a nice place to start, because edolstra provides constructive opposition to whole SAL idea. Should SAL support socket activation? Should we find Greatest Common Factor of service supervisors? Will it remove work for NixOS maintainers or add more? Is NixOS module system even good enough for SAL?

PR: Create service abstraction layer (proposal, prototype) by offlinehacker

A monumental, original SAL proposal. Abstracted over Docker, systemd and supervisord. But not without problems and abstraction leaks. edolstra rejected it in-fact (or rather, didn't support), and PR author burned out on this idea.

I'm closing this pull request, as after two years of dealing with docker, kubernetes and other containarized environments, i have much better idea how nix-services should be designed. ... This work is from my perspecitve obsolete.

Develop a universal web service definition

Another idea about finding greatest common factor, this time for web services (nginx, httpd, etc).

Multiple services of one type

You can start several service instances on a machine. For example, 2 postgresql services, 3 sshd servers and so on. All you have to do is specify different port and statefile in different configs before launching. Why then NixOS forces us to have one instance of service of a particular type?

comment: my idea is... by lethalman

This originated from SAL PR.

My idea of multi instances is to have multiple instances of the service :P Instead of e.g. one nginx httpd, you can define multiple nginx httpd using different versions for example. E.g. pgsql 9.3 and pgsql 9.4.

PR: Problem attempting to mkMultiInstance by lethalman

Continue of previous thought. Has backward compatibility. Multiple services should be defined like this:

example.nix

  services.nginx = {
    enable = true;

    instances.foo = {
      enable = true;
    };
  };

This was closed with words "Why not use multiple instances of declarative containers when you want multiple instances of a service?"

external: nixsap by ip1981

The most advanced and likely not dead approach at multiple instances. As an extension to NixOS, you can use multiple services alongside NixOS original ones. Drawback is that its service configuration is different from NixOS one, and thus, not many services are available.