Qube per appvm app manager

[slg407]

The problem you're addressing (if any)

Currently the options are to use snap or flatpak with the --user tag to install apps in appVMs, or to add the app to the overall template, and depending on the app it will not save app states between reboots:

For example if i configure an app that doesn't store settings in the user folder a certain way for one appVM and another way for another appVM, I have to clone the template and make the exact same template again.

Or if i want to have risky disposable qubes that should have barebones installs i'd have to make a disposable template separately from the other templates.

The solution you'd like

RPM ostree works similarly to a git tree:

Package installs should not happen at the OS template level, but instead fork into git style branches depending on the qube, reusing packages if they are already available.

Qubes should give the option to set up these app templates to either:

1-Do an initial setup that gets applied every boot, afterwards persist user changes OS wide between boots, if the user wants to.

2- Do an initial setup that gets applied every boot (but changes between boots are wiped).

3- Or to start fresh every time.

Example: base fedora template -> common packages between qubes 1, 2, 3 ->

1- qube 1 additional packages -> qube 1 user setup -> qube 1 last boot changes -> qube 1-> save changes to an overlay similar to RPM-ostree, apply on next boot.

2- qube 2 additional packages -> qube 2 user setup -> qube 2 -> wipes changes between boots except for user folder unless its set as disposable

3- qube 3 additional packages -> qube 3 -> wipe all changes on reboot except for user folder unless its set as disposable -> start fresh (same as the current behavior for appVMs)

This should be manageable from the qubes manager GUI

Packages should be stored in a sys-tree-vault qube containing different versions of packages used by different qubes:

If edits to files during user-setup are equal they are merged into branches to save disk space.

Branches should can also be used to make tree style app templates (allowing for user initial configs to be shared between qubes, without affecting the base OS template)

If necessary a second reference sys-tree-vault could also be added to mitigate any future exploit risks that might attempt to infect the vault:

This would be similar to A/B android systems (but with vault qubes), which checks for vault integrity and allows users to revert to a previous state.

There should also be the ability for users to make their own app templates.

Example: The OS templates only include the minimal base OS. If the user wants fedora-43-xfce, they will have to install the xfce app template over the fedora-43-minimal base OS template.

The value to a user and who that user might be

Less disk space usage, easier setup of packages, better experience in general.

Every user would benefit from this, especially those that can't spend hours setting up and troubleshooting every time they want to do anything productive.

It would also make qubes way easier to deploy, manage and use.

Additionally this would increase security:

Preinstalled packages in OS templates could be used as parts of exploits/exploit-chains, so being able to granularly control what gets added to what qube would make the entire OS safer.

Completion criteria checklist

No response

[ben-grande]

From what I understood, this seems to be a duplicate of another issue (that I did not find yet), that Nix package manager users, NixOS and Guix, would also like (but not exclusively to them), to have descendants be rebuilt with different packages without having the requirement of multiple templates. I'd be glad if someone can point to related or duplicate issues. Or, if that is not a duplicate issue, I'd appreciate fixing the writing of the first post.

Informal writing style of the first post (RESOLVED).

Look I appreciate the detailed write up, I've seen you put an effort in that, but this is hard to read.

I have seen this trend of a conscious stylistic effort of informal writing on a formal venue (which I don't know if it's your case, but your grammar is on point), that overtime feels natural to the writer, of not capitalizing things or not having periods. This makes it very hard to find the extremes of a sentence and grasp what the writer meant.

If this style comes from your mother-language, which I don't think so because I didn't notice grammar mistakes, only informal writing, please still put some effort at capitalizing and punctuation. If I notice you put an effort in writing, I will put an effort in reading.

This is a public venue, please write as if you'd like to be understood by others, not just by yourself. English is not my mother-tongue.

[slg407]

From what I understood, this seems to be a duplicate of another issue (that I did not find yet), that Nix package manager users, NixOS and Guix, would also like (but not exclusively to them), to have descendants be rebuilt with different packages without having the requirement of multiple templates. I'd be glad if someone can point to related or duplicate issues. Or, if that is not a duplicate issue, I'd appreciate fixing the writing of the first post.
Informal writing style of the first post.

Look I appreciate the detailed write up, I've seen you put an effort in that, but this is hard to read.

I have seen this trend of a conscious stylistic effort of informal writing on a formal venue (which I don't know if it's your case, but your grammar is on point), that overtime feels natural to the writer, of not capitalizing things or not having periods. This makes it very hard to find the extremes of a sentence and grasp what the writer meant.

If this style comes from your mother-language, which I don't think so because I didn't notice grammar mistakes, only informal writing, please still put some effort at capitalizing and punctuation. If I notice you put an effort in writing, I will put an effort in reading.

This is a public venue, please write as if you'd like to be understood by others, not just by yourself. English is not my mother-tongue.

sorry about that, you are correct in saying english is not my first language, i will edit the post to reword it after i come back from work

[ben-grande]

english is not my first language

You could try some LLMs for restructure text, and hope they do not change the meaning of what you intended to say...

[slg407]

From what I understood, this seems to be a duplicate of another issue (that I did not find yet), that Nix package manager users, NixOS and Guix, would also like (but not exclusively to them), to have descendants be rebuilt with different packages without having the requirement of multiple templates. I'd be glad if someone can point to related or duplicate issues. Or, if that is not a duplicate issue, I'd appreciate fixing the writing of the first post.
Informal writing style of the first post.

i updated the post to have better paragraphs and punctuation

[ben-grande]

Thank you for editing the first post. I think it is much easier to understand what you meant, and I believe I could understand some things even more. I will hide these last comments as outdated.

[slg407]

Thank you for editing the first post. I think it is much easier to understand what you meant, and I believe I could understand some things even more. I will hide these last comments as outdated.

I hope my feature request is useful. (and that you like it too)

I'm sure implementing something like this could help bring Qubes to non-technical users that are at risk of certain threats, but lack the technical know-how or patience to use Qubes in it's current state. (example: Journalists, members of grassroots social and political movements, public workers in different countries, etc.)

This is why i see this feature as being crucial for the future of Qubes, it would make the OS usable and accessible for those that need it.

[ben-grande]

I believe that the current blocker, as per my last discussion on this topic with Marek, was that the way the template system works is with block devices, and they are not suitable for such use cases, of finer granularity. Still, would be something nice to have.