Previous meeting: #1 2026-05-26
Attendees: @aanderse, @roberth, @tomberek, @eveeifyeve, @kiara, @lassulus
-
@Eveeifyeve: been working on this serviceManager API, got a branch up
-
@tomberek: we should be aware of @svanderburg’s earlier work, RFC 163, nix-processmgmt
- @roberth: i’ve been aware of it, and he discovered many of the options we might want, tho he and i agreed his wasn’t very NixOS-like (many functions), so we should adapt the concepts
-
@Eveeifyeve: php-fpm’s adaptations to different environments (NixOS, finix) could just use shims
-
@kiara: Are we modeling a lowest common denominator
-
@aanderse: I think we’re modeling various information attributes
-
?: risk of playing favorites
-
@kiara: if we wanna support environment-specific stuff, will we get one giant frankenstein interface? or keep to info useful to multiple environments?
-
@roberth: environment-specific interfaces could just help for consistency (rather than as an abstraction)
-
@kiara: how do we avoid just wrapping environment-specific options then?
-
@tomberek: what about other use cases?
-
@aanderse: how would k8s fit into the picture: k8s can use MS or MS supports k8s?
-
@kiara: I’m interested in this use case. It fills a gap between NixOS and k8s. Experimenting with this for Fediversity
-
@tomberek: distributed systemd is something I would expect to evolve in the ecosystem at some point
-
@kiara:
Kelsey Hightower when talking about about the gap between NixOS vs Kubernetes mentioned having done CoreOS before- looks like that wasn’t actually distributed, never mind -
@aanderse: I don’t think systemd has those ambitions. Nomad was closer to what you’re talking about, but wasn’t a viable k8s - abandoned (+ switched to BSL)
-
@roberth: a missing ingredient for this kind of thing is mutable units
-
@aanderse: deploy-rs may support or consider this
-
@aanderse: we could support evaluating systemd units based on modular services. Small amount of work to support this use case
-
@aanderse: finit supports ad hoc services in /run too.
-
@tomberek: decoupling of infrastructure and control plane is helpful. Disnix also did this nicely
-
@aanderse: doesn’t model cross-service interactions between the mutable part and the system part
-
@tomberek: nixos-containers could be part of the pattern here. Coupled things go into your infra layer, and the rest can go into the container-based service layer. The layers are declared independently.
-
@aanderse: @phaer is doing some cool work on decoupling in NixOS.
-
@EveeifyEve: any blockers for integration with NixBSD?
-
@aanderse: They’re interested, no active efforts to start integrating so far. They also have a different finit integration.
-
@EveeifyEve: what other integrations are missing that would help people? e.g. dev-env, services-flake, nixbsd
-
@aanderse: Those are all valid gaps to fill, but we should focus last meeting’s plan.
-
@roberth: Not before we’ve figured out a number of options
-
@roberth: here’s a branch for testing modular services in a portable fashion: Comparing NixOS:master...roberth:modular-services-compliance-suite · NixOS/nixpkgs · GitHub
Housekeeping
-
@aanderse: Meeting is biweekly
-
@aanderse: Let’s avoid analysis paralysis. For instance, backcompat is not a concern
-
actions
- async: answer @eveeifyeve’s questions
- roberth: finish platform-generic “compliance” test
- roberth: review
environmentPR - kiara: continue on PRs
- docs
- user-service
- lassulus: continue on flags PR