The talk explains use of NixOS code as a library instead of a framework: the present, the possible even better future, and some of the payoff. Nix package manager has a lot of useful properties, and NixOS permits to expand the use of such properties beyond just installing packages. However, while Nixpkgs behaves mostly like a library, with overrides sometimes used to change even the fundamental assumptions if these are not used by some packages (see, e.g., pkgsMusl), NixOS is typically perceived closer to a framework. Using NixOS service management means committing to the module system (but Nixpkgs overrides are still useful), nonatomic /etc switch, systemd, NixOS driver management, etc. This creates a leap of faith, as installing Nix side-by-side breaks only storage quotas, but installing NixOS breaks everything; and leads to some duplication with nix-darwin and similar projects. In the talk I will tell what and how to reuse from NixOS now, what NixOS changes could simplify use of NixOS as a shared knowledge collection about running services between different projects with different commitment level, and how a bit of commitment to dumping the core assumptions turns some features from a weird dream into table stakes.