And then there is NixOS

This is true, and the article made me think if such a standard a) could while remaining meaningful b) should be written to accommodate setups like that.

I think it can, and arguably should. In order to accomplish this, you need a layer of indirection: Standardize *roles* and *invariants*, not specific implementation details. Think "what exactly needs to be true at runtime", not "where exactly vendor bits live on disk".

Define a *small set of normative invariants* about roles (code, policy, runtime, state) and their lifecycle (read-only vs writable, ephemeral vs persistent), then provide *profiles* that map those roles to paths. Classic distros, immutable images, containers, and Nix/Guix can all conform by choosing an appropriate profile (or declaring a custom one) while preserving interoperability.

To be standardized (MUST or SHOULD):

1. Roles, not paths.

Vendor content: executable code, static data shipped by the OS/vendor. MUST be treatable as read-only at runtime.

Admin policy: local configuration overriding vendor defaults. MUST be writable and take precedence over vendor content.

Runtime state: sockets, pid files, transient caches. MUST NOT survive a reboot.

Persistent state: databases, logs, package metadata, app state. MUST survive a reboot and be writable.

2. Precedence and merge.

Admin policy MUST override vendor defaults via a deterministic precedence order (e.g., /etc ≻ vendor config).

3. Discoverability.

The locations implementing each role MUST be discoverable at runtime via well-defined mechanisms (e.g., environment variables, a machine-readable file, or stat(2)-detectable mounts), so software doesn't have to hard-code paths.

4. Stability guarantees.

Persistent state paths SHOULD remain stable across OS upgrades; runtime paths MAY be tmpfs and cleared at boot.

5. Graceful fallback.

If a profile doesn't provide an alternative location, well defined sane defaults apply.

---

With this, a classic FHS style system would map vendor=/usr (ro-capable), admin_policy=/etc, runtime=/run, persistent_state=/var.

NixOS could declare something like vendor=/nix/store (ro) with profile views under /run/current-systems/sw exposing POSIX paths, admin_policy=/etc (generated from declarative config but still the top of precedence), runtime=/run, persistent_state=/var. NOTE: the spec would not require vendor content to be under /usr, but only discoverable.

Discovery mechanisms could be something like a simple configuration file pointed to by an environment variable or in a standard location like /run/fs-roles.d/active.json, and/or just env vars.

> Even systemd's file-hierarchy is not flexible enough for the way NixOS does things!

https://imgur.com/a/nix-Qso4ddc