Custom persist should replace named disposables based on templates?

I’ve experimented with custom-persist a little, and I think it should completely replace the current template persistence for named disposables like this:

  • Add an option for custom-persist to have files reset on boot, like current template architecture already does.
  • Make an option for named disposables straight from templates.

There. If you want a named disposable with customization, use custom-persist. If you want an empty disposable, then just base it on a template. If you want the dispXXXX disposables, then you have the usual way.


This is meant to be a suggestion, just phrased this way because I’m trying to template out a system, and I wish it were simpler instead of having to manage ten different dvm-templates for ten different nameed disposables simply because they have different templates. Feels like wasted space, even moreso for the ones that need customization. Take this with a grain of salt.

1 Like

I completely agree.

Seeing my work on separated sys-xxx service qubes, all generated as named disposables, it would be much easier to check only one source for configuring them instead of two as is now.

Any configuration details used within the service qubes could be derived directly out of the normal templates in combination with using the Qubes DB directly on the named disposables. (as used in sys-net for saving the wifi credentials …)

Maybe someone has an idea, but I can’t see anything, what can’t be don’t this way.