sync machine and home state with impermanence

[blaggacao]

"Q5 / Future Thinks + No Budget"-office here again. 😉

I stumbled over https://git-annex.branchable.com/ and it looks like a suitable idea on how to manage user state.

cc/ @cole-h since his readme prominently exposes the challenge.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[blaggacao]

Though gitlab decided to drop support a while ago in favor of git lfs, details: https://gitlab.com/gitlab-org/gitlab/-/issues/1648

On the other hand git annex supports "special remotes", including git LFS, which makes git annex a super versatile tool for syncing state to whatever service is preferred.

[jorsn]

@blaggacao What do you mean by “user state” exactly? Only immutable state provided by “the system”?

Things to consider:

1. You only need git-annex for large files, so not password files etc.
2. It ties you completely to git, which hinders progress (look e.g. at pijul)
3. Git-annex only has gains over plain (possibly encrypted) git-lfs if you want to have a partial state in some repos and configure the spread of the data over the repositories.
4. At least you'd have to handle unlocking+locking/commiting of files as by default everything is immutable and referenced by symlinks.
5. For mutable files/non-symlink mode git-annex uses gits smudge/clean filters which the whole file is in principle piped through (though git-annex uses some tricks there). This is inefficient if you don't really need these filters.
6. Yet another really complex component of this system. Nix + git-annex + dhall + systemd for a basic system looks a bit complex to be suitable for a “community consensus on how to manage a NixOS system”, which should also be understandable by beginners (Simplify devos #137).

For mutable state: What about dysnomia?

[blaggacao]

Those are very thoughtful points, thank you!

I'm especially intrigued by pijul which seems to be a modern alternative to sqlite's fossil. I will keep an eye on it.

What do you mean by “user state” exactly? Only immutable state provided by “the system”?

Not sure.

In principle, git lfs does the job of putting blobs under the same workflow as system state, too. I have no understanding if pijul/fossil have a similar feature.

A vcs based workflow might serve two goals, in this context:

• snapshotting
• syncing (between hosts)

Dysnomia sounds interestingly convoluted which might or might not constitute a quality attribute (which I'm far from able to judge). I hope the docs get more accesible as the project evolves.

Maybe we actually need syncing and snapshotting only as a useful afterthought for some classes of state?

(hypothetocally)

[ctem]

Impermanence is very handy and easy to use. It is intended for hosts with root file systems that do not persist between reboots—a strategy I also generally recommend—but is useful for consolidation of mutable state regardless. The chosen path(s) (e.g., /persistent from environment.persistence."/persistent") can then be managed as independent repositories as desired for versioning, backup, deployment, etc.

[blaggacao]

This is a really cool suggestion! Thanks.

[blaggacao]

It would be really cool for devos to be able to consume something like nix-community/impermanence#40 and wire up a state synchronization between hosts (e.g. with syncthing).