[Tainnor]

Sounds interesting in theory, but modern development setups are often full with tools, dependencies, IDE indices, intermediate build results, etc. pp. that all may take a very long time to download and build from scratch. Sure, you could try to keep track of all such things and persist them but it's going to be a lot of effort trying to figure out where all your tools are dumping their state.

[solatic]

I don't think of impermanence as a tool for development setups, but rather a tool to improve production security. When a server gets compromised, it's common for an attacker to leverage their initial access to set up backdoor access for themselves, e.g. an additional privileged user or privileged service which phones home, so that they're no longer reliant on the original vulnerability to gain access again. This is important to ensure that they can launch a more damaging attack at a more opportune time (e.g. at the beginning of a long weekend). Now consider a stateful server which you need to host (e.g. Kubernetes control plane / etcd) where you ordinarily cannot practice immutable infrastructure due to the stateful nature of the server. Modules like impermanence allow you to guard against this kind of compromise by simply wiping out everything but the actual state as a result of rebooting. Any privileged users or malicious processes (which, of course, are not part of the system configuration used at boot) get wiped out at every reboot. It's not a silver bullet - an attacker could simply releverage the original vulnerability and set up access again - but doing the reboots frequently would force the vulnerability to be re-exploited each time, making it a pattern of access more likely to be detected in a SIEM.

[yjftsjthsd-h]

> often full with tools, dependencies, IDE indices, intermediate build results

Tools and dependencies go in nix. Indexes and temporary build stuff is just cache, which you can still have (I'd lean towards regenerating per reboot, but YMMV).

> but it's going to be a lot of effort trying to figure out where all your tools are dumping their state.

Fair. Kind of an indictment of the current state of the ecosystem, but yes.

[n42]

it's not so difficult, really. most of this is in your home folder, which is just a separate persistent mount.

you can also use impermanence with home-manager if you want

https://github.com/nix-community/impermanence#home-manager

[Tainnor]

Sure, but then you're throwing away the purported benefits (setup is always reproducible) for your entire home folder.

It seems like there are two contradictory goals here, each with their own benefits. Impermanence gives you reproducibility, but permanence gives you performance.

Maybe the right tradeoff is to just persist the entire home folder and nothing else (or few other things... I'm not sure I'd want to always download some programs that are quite huge), but the tradeoff is essentially still there.

[n42]

you're talking about three different things: NixOS, Home Manager, and Impermanence. or put another way: reproducible root filesystem, reproducible home folder, automatically reproducing things on boot.

if you want a reproducible root filesystem, use NixOS. if you want to reproduce your root filesystem on boot, use NixOS with impermanence.

if you want a reproducible home folder, use home manager. if you want to reproduce your home folder on boot, use home manager with impermanence.

I only use impermanence on servers. I don't think there's any point using it on a desktop, or with Home Manager, other than street cred. it just complicates things. I don't really even recommend Home Manager for first time NixOS users for the same reason.

edit: and I want to address this comment:

> I'm not sure I'd want to always download some programs that are quite huge

this isn't how it works; the binaries, as well as the entire initial state of the filesystem, are cached in the Nix cache, a read-only filesystem. you're not downloading everything on every boot.

[Cloudef]

With NixOS, you typically use flake.nix or shell.nix to "shell into" development environment so this is kinda non issue. You can also use `nix run` or `nix-env` to mix traditional package management and this.

> but it's going to be a lot of effort trying to figure out where all your tools are dumping their state.

This is true though, if you dont want to manage all of their configs from nix, I would make their dump locations, or $XDG_DIRS/$HOME (if you are lazy) permanent in this case.