impermanenced

[blaggacao]

I imagine a super leightweight impermanenced which helps setting up a sytemd cron job for syncing whole state folders with either 1) rsync or 2) syncthing wired up.

This can be thought of as a convenience service to give a hand to less-than-power-users.

Context: https://github.com/divnix/devos/discussions/180#discussioncomment-497912

[cole-h]

I see this as unrelated to the purpose of impermanence (except as a means of consuming the configuration). Although I don't yet use it, I envision this project as just a way to ease managing state directories for systems with an ephemeral root (or similarly ephemeral directories). Syncing of state between machines is, IMHO, out of scope.

If you wanted to create a service to sync these state dirs yourself, you could do so by accessing config.home.persistence.${state path} or config.environment.persistence.${state path} and hooking something up that way.

That said, I won't close this in case some of the other, more involved members disagree with me.

cc @lovesegfault @talyz

[blaggacao]

I completely can see where you are coming from.

But let me ask you this: What is your philosophy on "blessed paths" as a tool for new users to find themselves around in the ecosystem? Kind of an adaption of "batteries included, but swap-able".

Lack of consistent, structured (and upstream owned) guidance on even not-so-exotic use cases is one of the top complaints I hear from new users across the aisle, and I'm also affected. I'm not so much a fan of "figure that out yourself" as a baseline stance: it feels a bit like putting forth software without integration testing it (in a figurative sense).

EDIT: Also, upstream owned guidance typically fosters discussion evolving around different use cases and the spread of ideas.