invent term for DisposableVM-TemplateVM and add to glossary

[adrelanos]

https://www.qubes-os.org/doc/glossary/

debian-8 or whonix-ws we call TemplateVM

debian-8-dvm or whonix-ws-dvm - How to call those? DisposableVM-TemplateVM?

I'd like to add them to the glossary.

(Such a term would have been useful during a technical discussion.)

[adrelanos]

Or DisposableVM-Template?

[adrelanos]

Or DisposableVM-Template?

[andrewdavidwong]

I agree that we should formalize this terminology. I've personally been using DVM Template for a long time now.

[andrewdavidwong]

I agree that we should formalize this terminology. I've personally been using DVM Template for a long time now.

[andrewdavidwong]

@adrelanos: Also see the existing entry DVM.

@marmarek: Any opinion?

[andrewdavidwong]

@adrelanos: Also see the existing entry DVM.

@marmarek: Any opinion?

[adrelanos]

DVM alone is non-ideal, could be an abbreviation for "DisposableVM". On the other hand DVM has the advantage of being included in for example whonix-ws-dvm, visible in QVMM. I prefer DisposableVM-TemplateVM since it leaves least room for interpretation. Not so much Disposable-TemplateVM since that could be misunderstood as a TemplateVM somehow started disposable mode.

[adrelanos]

DVM alone is non-ideal, could be an abbreviation for "DisposableVM". On the other hand DVM has the advantage of being included in for example whonix-ws-dvm, visible in QVMM. I prefer DisposableVM-TemplateVM since it leaves least room for interpretation. Not so much Disposable-TemplateVM since that could be misunderstood as a TemplateVM somehow started disposable mode.

[marmarek]

Note that in Qubes 4.0, this term will apply to any AppVM with appropriate flag enabled: #866 (comment).

What about DisposableVM-template (drop second VM)?

[marmarek]

Note that in Qubes 4.0, this term will apply to any AppVM with appropriate flag enabled: #866 (comment).

What about DisposableVM-template (drop second VM)?

[andrewdavidwong]

DVM alone is non-ideal, could be an abbreviation for "DisposableVM". On the other hand DVM has the advantage of being included in for example whonix-ws-dvm, visible in QVMM.

I agree. My suggestion was "DVM Template," not "DVM" alone. (The link to "DVM" was simply because it's related.) What do you think of that?

I prefer DisposableVM-TemplateVM since it leaves least room for interpretation.

It seems to me that our goal should be the opposite. Instead of leaving room for interpretation, we should remove all ambiguity so that there is no danger of talking past each other.

Edit: Sorry, I misread your statement. It looks like we're in agreement about the goal.

Note that in Qubes 4.0, this term will apply to any AppVM with appropriate flag enabled: #866 (comment).

Ah, that's a good point. This greatly reduced the need to have a separate term. Still, it wouldn't hurt to have one.

What about DisposableVM-template (drop second VM)?

After thinking about it some more, I believe that "DVM Template" (or "DVM template" or "DVM-template" should be preferred over "DisposableVM-template" (or "DisposableVM-Template" or "DisposableVM-TemplateVM") for two reasons:

1. -dvm is already appended to the actual template name in order to indicate that it is the DVM template. To maintain consistency, the same indicator ("DVM") should be used in the generic term encompassing all such VMs.

2. "DisposableVM-template" is ambiguous. It could mean "the TemplateVM on which a DispVM is ultimately based, " e.g., fedora-24. There is a much smaller chance that "DVM template" will be interpreted in this way, since "DVM" is not used to refer to anything except the DVM template.

[andrewdavidwong]

DVM alone is non-ideal, could be an abbreviation for "DisposableVM". On the other hand DVM has the advantage of being included in for example whonix-ws-dvm, visible in QVMM.

I agree. My suggestion was "DVM Template," not "DVM" alone. (The link to "DVM" was simply because it's related.) What do you think of that?

I prefer DisposableVM-TemplateVM since it leaves least room for interpretation.

It seems to me that our goal should be the opposite. Instead of leaving room for interpretation, we should remove all ambiguity so that there is no danger of talking past each other.

Edit: Sorry, I misread your statement. It looks like we're in agreement about the goal.

Note that in Qubes 4.0, this term will apply to any AppVM with appropriate flag enabled: #866 (comment).

Ah, that's a good point. This greatly reduced the need to have a separate term. Still, it wouldn't hurt to have one.

What about DisposableVM-template (drop second VM)?

After thinking about it some more, I believe that "DVM Template" (or "DVM template" or "DVM-template" should be preferred over "DisposableVM-template" (or "DisposableVM-Template" or "DisposableVM-TemplateVM") for two reasons:

1. -dvm is already appended to the actual template name in order to indicate that it is the DVM template. To maintain consistency, the same indicator ("DVM") should be used in the generic term encompassing all such VMs.

2. "DisposableVM-template" is ambiguous. It could mean "the TemplateVM on which a DispVM is ultimately based, " e.g., fedora-24. There is a much smaller chance that "DVM template" will be interpreted in this way, since "DVM" is not used to refer to anything except the DVM template.

[andrewdavidwong]

[Reposting my edit as a separate message so that it triggers a GitHub notification.]

I prefer DisposableVM-TemplateVM since it leaves least room for interpretation.

It seems to me that our goal should be the opposite. Instead of leaving room for interpretation, we should remove all ambiguity so that there is no danger of talking past each other.

Edit: Sorry, I misread your statement. It looks like we're in agreement about the goal.

[andrewdavidwong]

[Reposting my edit as a separate message so that it triggers a GitHub notification.]

I prefer DisposableVM-TemplateVM since it leaves least room for interpretation.

It seems to me that our goal should be the opposite. Instead of leaving room for interpretation, we should remove all ambiguity so that there is no danger of talking past each other.

Edit: Sorry, I misread your statement. It looks like we're in agreement about the goal.

[entr0py]

"DisposableVM-template" is ambiguous. It could mean "the TemplateVM on which a DispVM is ultimately based

Bah, only an idiot would make the mistake of confusing that with a "DisposableVM-Template-TemplateVM". ;)

[entr0py]

"DisposableVM-template" is ambiguous. It could mean "the TemplateVM on which a DispVM is ultimately based

Bah, only an idiot would make the mistake of confusing that with a "DisposableVM-Template-TemplateVM". ;)

[andrewdavidwong]

Bah, only an idiot would make the mistake of confusing that with a "DisposableVM-Template-TemplateVM". ;)

:)

In seriousness, though, are you suggesting that "DisposableVM-template" may not actually be ambiguous in the way I thought?

[andrewdavidwong]

Bah, only an idiot would make the mistake of confusing that with a "DisposableVM-Template-TemplateVM". ;)

:)

In seriousness, though, are you suggesting that "DisposableVM-template" may not actually be ambiguous in the way I thought?

[entr0py]

I can't speak for others on that - especially non-English speakers. Personally, it doesn't seem ambiguous to me because in general usage, something-template usually refers to a template for something - like "business letter template" is a template for business letters. So DisposableVM-Template would be a template for DisposableVMs. However, I'm not sure that entirely solves the ambiguity issue that you raised. Perhaps the only way to completely remove the ambiguity is to also explicitly declare a name for what you were referring to: a DisposableVM-Template-TemplateVM. Maybe "DisposableVM-Base-Template", "DisposableVM-Root-Template", or "TemplateVM that DisposableVM-Template is based on". We are really getting into the weeds now...

I'll add that there's not as much opportunity for ambiguity because it is a two-layered system, and there aren't many situations where you are discussing disp1, disp2, ... and have to refer back to the Base-TemplateVM. That was my experience working on Whonix guide anyway.

[entr0py]

I can't speak for others on that - especially non-English speakers. Personally, it doesn't seem ambiguous to me because in general usage, something-template usually refers to a template for something - like "business letter template" is a template for business letters. So DisposableVM-Template would be a template for DisposableVMs. However, I'm not sure that entirely solves the ambiguity issue that you raised. Perhaps the only way to completely remove the ambiguity is to also explicitly declare a name for what you were referring to: a DisposableVM-Template-TemplateVM. Maybe "DisposableVM-Base-Template", "DisposableVM-Root-Template", or "TemplateVM that DisposableVM-Template is based on". We are really getting into the weeds now...

I'll add that there's not as much opportunity for ambiguity because it is a two-layered system, and there aren't many situations where you are discussing disp1, disp2, ... and have to refer back to the Base-TemplateVM. That was my experience working on Whonix guide anyway.

[jpouellet]

Is there some reason we are trying to avoid spaces? To me:

• DisposableVM-Template easily reads as "disposable {vm-template}" (which in 3.2 context sounds like some kind of TemplateVM which is intended to be short-lived for some reason...? ¯_(ツ)_/¯ )
• DisposableVM Template imho is perhaps more unambiguously a "{disposable vm} template"

@adrelanos your technical discussion example link is just a link to the glossary

[jpouellet]

Is there some reason we are trying to avoid spaces? To me:

• DisposableVM-Template easily reads as "disposable {vm-template}" (which in 3.2 context sounds like some kind of TemplateVM which is intended to be short-lived for some reason...? ¯_(ツ)_/¯ )
• DisposableVM Template imho is perhaps more unambiguously a "{disposable vm} template"

@adrelanos your technical discussion example link is just a link to the glossary

[andrewdavidwong]

Is there some reason we are trying to avoid spaces?

If you read my comments, you'll see that I'm not particularly trying to avoid spaces. I assume that @adrelanos and @marmarek are doing so in the interest of allowing for the same string to be used in code and on the command-line as in natural language conversation.

[andrewdavidwong]

Is there some reason we are trying to avoid spaces?

If you read my comments, you'll see that I'm not particularly trying to avoid spaces. I assume that @adrelanos and @marmarek are doing so in the interest of allowing for the same string to be used in code and on the command-line as in natural language conversation.

[adrelanos]

Andrew David Wong:

> Is there some reason we are trying to avoid spaces? If you read my comments, you'll see that I'm not particularly trying to avoid spaces. I assume that @adrelanos and @marmarek are doing so in the interest of allowing for the same string to be used in code and on the command-line as in natural language conversation.

I am doing this because I think otherwise the likelihood of people using contractions increases. It also highlights, that it's a term we coined (when users are talking to each other) and not just a description where others later come up with creative new versions. Example: I prefer TemplateBasedVM over template based VM.

[adrelanos]

Andrew David Wong:

> Is there some reason we are trying to avoid spaces? If you read my comments, you'll see that I'm not particularly trying to avoid spaces. I assume that @adrelanos and @marmarek are doing so in the interest of allowing for the same string to be used in code and on the command-line as in natural language conversation.

I am doing this because I think otherwise the likelihood of people using contractions increases. It also highlights, that it's a term we coined (when users are talking to each other) and not just a description where others later come up with creative new versions. Example: I prefer TemplateBasedVM over template based VM.

[adrelanos]

Jean-Philippe Ouellet:

@adrelanos your technical discussion example link is just a link to the glossary

These were those technical discussions. - https://forums.whonix.org/t/using-whonix-workstation-as-a-disposablevm-dispvm - https://forums.whonix.org/t/qubes-dispvm-technical-discussion

[adrelanos]

Jean-Philippe Ouellet:

@adrelanos your technical discussion example link is just a link to the glossary

These were those technical discussions. - https://forums.whonix.org/t/using-whonix-workstation-as-a-disposablevm-dispvm - https://forums.whonix.org/t/qubes-dispvm-technical-discussion

[unman]

I would prefer to use dvm - no reference to template at all.
It has the advantage that it appears in the lists of VMs, and the role is easy to explain.
I do not think it likely that it will be confused with DispVM.
It also avoids confusion between the role of the Template and the role of the dvm. (There is a slight confusion in the docs as they stand as to whether the dvm is a Template or an AppM.)

In the new implementation, we will need to distinguish between DispVMs based on dvms and those which are AppVMs opened in disposable mode. I don't think that using "Template" here will help with this distinction.
Don't invent a new term: just repurpose the existing one, and change the definition in the glossary.

[unman]

I would prefer to use dvm - no reference to template at all.
It has the advantage that it appears in the lists of VMs, and the role is easy to explain.
I do not think it likely that it will be confused with DispVM.
It also avoids confusion between the role of the Template and the role of the dvm. (There is a slight confusion in the docs as they stand as to whether the dvm is a Template or an AppM.)

In the new implementation, we will need to distinguish between DispVMs based on dvms and those which are AppVMs opened in disposable mode. I don't think that using "Template" here will help with this distinction.
Don't invent a new term: just repurpose the existing one, and change the definition in the glossary.

[andrewdavidwong]

I would prefer to use dvm - no reference to template at all.
It has the advantage that it appears in the lists of VMs, and the role is easy to explain.

Arguably, any term containing "DVM" has the same advantage, including "DVM Template."

I do not think it likely that it will be confused with DispVM.

Perhaps not, but in the context of Qubes, what else could "DVM" be an acronym for besides "Disposable Virtual Machine"? Maybe the best option is to change it to "DVMT" (including changing the VM suffix to -dvmt) and use that?

It also avoids confusion between the role of the Template and the role of the dvm. (There is a slight confusion in the docs as they stand as to whether the dvm is a Template or an AppM.)

I think that's a legitimate confusion. It arises because the actual implementation is somewhat confusing. The DVM Template is sort of "in-between" a TemplateVM and an AppVM: Unlike most TemplateVMs and like most AppVMs, it's a TemplateBasedVM. Unlike AppVMs and like TemplateVMs, its function is not running apps but rather supplying a read-only copy of its filesystem to VMs based upon it.

In the new implementation, we will need to distinguish between DispVMs based on dvms and those which are AppVMs opened in disposable mode. I don't think that using "Template" here will help with this distinction.

This strikes me as orthogonal to the issue. The term for X needs to help us distinguish X from other things; it doesn't need to help us distinguish Y from Z.

Don't invent a new term: just repurpose the existing one, and change the definition in the glossary.

I am not strongly opposed to the suggestion, but I still think "DVM Template" is less ambiguous and retains all the advantages of just "DVM." Either one will probably be fine, though.

[andrewdavidwong]

I would prefer to use dvm - no reference to template at all.
It has the advantage that it appears in the lists of VMs, and the role is easy to explain.

Arguably, any term containing "DVM" has the same advantage, including "DVM Template."

I do not think it likely that it will be confused with DispVM.

Perhaps not, but in the context of Qubes, what else could "DVM" be an acronym for besides "Disposable Virtual Machine"? Maybe the best option is to change it to "DVMT" (including changing the VM suffix to -dvmt) and use that?

It also avoids confusion between the role of the Template and the role of the dvm. (There is a slight confusion in the docs as they stand as to whether the dvm is a Template or an AppM.)

I think that's a legitimate confusion. It arises because the actual implementation is somewhat confusing. The DVM Template is sort of "in-between" a TemplateVM and an AppVM: Unlike most TemplateVMs and like most AppVMs, it's a TemplateBasedVM. Unlike AppVMs and like TemplateVMs, its function is not running apps but rather supplying a read-only copy of its filesystem to VMs based upon it.

In the new implementation, we will need to distinguish between DispVMs based on dvms and those which are AppVMs opened in disposable mode. I don't think that using "Template" here will help with this distinction.

This strikes me as orthogonal to the issue. The term for X needs to help us distinguish X from other things; it doesn't need to help us distinguish Y from Z.

Don't invent a new term: just repurpose the existing one, and change the definition in the glossary.

I am not strongly opposed to the suggestion, but I still think "DVM Template" is less ambiguous and retains all the advantages of just "DVM." Either one will probably be fine, though.

[unman]

@andrewdavidwong I note your assumption that dvm has to be an acronym.

imo the current implementation isn't confusing, and as we move to the new implementation, ALL AppVMs will be able to provide read-only copies of the file system. Will that make them TemplateVMs? God forbid.
That is why this issue isn't "orthogonal".

[unman]

@andrewdavidwong I note your assumption that dvm has to be an acronym.

imo the current implementation isn't confusing, and as we move to the new implementation, ALL AppVMs will be able to provide read-only copies of the file system. Will that make them TemplateVMs? God forbid.
That is why this issue isn't "orthogonal".

[marmarek]

On Wed, Jan 11, 2017 at 08:34:39PM -0800, Andrew David Wong wrote: > It also avoids confusion between the role of the Template and the role of the dvm. (There is a slight confusion in the docs as they stand as to whether the dvm is a Template or an AppM.) I think that's a legitimate confusion. It arises because the actual implementation is somewhat confusing. The DVM Template is sort of "in-between" a TemplateVM and an AppVM: Unlike most TemplateVMs and like most AppVMs, it's a TemplateBasedVM. Unlike AppVMs and like TemplateVMs, its function is not running apps but rather supplying a read-only copy of its filesystem to VMs based upon it. > In the new implementation, we will need to distinguish between DispVMs based on dvms and those which are AppVMs opened in disposable mode. I don't think that using "Template" here will help with this distinction.

In context of terminology, the new implementation is the same: there is still an AppVM like ...-dvm, which is a sort of template for Disposable VM. The only difference is that user may have multiple such "sort of templates". And theoretically -dvm suffix is no longer required (but for the sake of clarity we may artificially enforce it). While implementation is that any AppVM could be started as Disposable VM, I think this is wrong thing to do. In fact we'll add explicit VM flag like "allow Disposable VMs based on this VM" (default to false).

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[marmarek]

On Wed, Jan 11, 2017 at 08:34:39PM -0800, Andrew David Wong wrote: > It also avoids confusion between the role of the Template and the role of the dvm. (There is a slight confusion in the docs as they stand as to whether the dvm is a Template or an AppM.) I think that's a legitimate confusion. It arises because the actual implementation is somewhat confusing. The DVM Template is sort of "in-between" a TemplateVM and an AppVM: Unlike most TemplateVMs and like most AppVMs, it's a TemplateBasedVM. Unlike AppVMs and like TemplateVMs, its function is not running apps but rather supplying a read-only copy of its filesystem to VMs based upon it. > In the new implementation, we will need to distinguish between DispVMs based on dvms and those which are AppVMs opened in disposable mode. I don't think that using "Template" here will help with this distinction.

In context of terminology, the new implementation is the same: there is still an AppVM like ...-dvm, which is a sort of template for Disposable VM. The only difference is that user may have multiple such "sort of templates". And theoretically -dvm suffix is no longer required (but for the sake of clarity we may artificially enforce it). While implementation is that any AppVM could be started as Disposable VM, I think this is wrong thing to do. In fact we'll add explicit VM flag like "allow Disposable VMs based on this VM" (default to false).

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[andrewdavidwong]

I note your assumption that dvm has to be an acronym.

It's not really an assumption; just an observation that, historically, "DVM" originated as an acronym for "Disposable Virtual Machine."

imo the current implementation isn't confusing

I didn't mean to denigrate the implementation. It's confusing because we lack a distinct concept and term for the "in-between template," but that's okay, because that's precisely what we're now hashing out.

and as we move to the new implementation, ALL AppVMs will be able to provide read-only copies of the file system. Will that make them TemplateVMs? God forbid. That is why this issue isn't "orthogonal".

According to our current definition of "TemplateVM,", yes. Now, the question is, how should we update this definition in light of the new functionality? Currently, "TemplateVM" (and, less formally, "template") denotes two things:

• A VM that provides its filesystem in read-only mode to other VMs.
• A VM that is not intended for running applications, only for installing them.

With the new functionality, these two things can be separated for the first time. So, we have to decide which one of them (if either) "template" will continue to apply to. It could go either way, but my impression is that the first thing (providing a read-only filesystem) is more strongly associated with "template." If we go with this, we would say things like, "In 4.0, AppVMs can now serve as templates for DispVMs." In that case, we should also come up with a term to refer to the other thing (a VM not intended only for installing apps, not running them). Perhaps a modifier like "base," as in "base template," would work here.

On the other hand, there would be an advantage to reserving "TemplateVM" to denote only the latter thing (a VM intended only for installing apps, not running them) insofar as it would allow us to formalize the "parent/child" terminology that has occasionally been used to describe the relationship between TemplateVMs and TemplateBasedVMs. This parent/child analogy is even more appropriate now that it's possible for many "children" to become "parents" with "children" of their own. If we go this route, we could say something like:

ParentVM: Any VM that provides its filesystem (in part or in whole) in read-only mode to a ChildVM.
ChildVM: Any VM that receives its filesystem (in part or in whole) in read-only mode from a ParentVM.

(The disadvantage of these definitions is that they don't distinguish between providing only the root filesystem, as TemplateVMs currently do, and providing the entire filesystem, as "DVM (Templates)" currently do.)

In context of terminology, the new implementation is the same: there is still an AppVM like ...-dvm, which is a sort of template for Disposable VM. The only difference is that user may have multiple such "sort of templates". And theoretically -dvm suffix is no longer required (but for the sake of clarity we may artificially enforce it).

I mostly agree, but there is one important difference: While fedora-24-dvm and work can both serve as "sort-of templates" for DispVMs, fedora-24-dvm is not intended for running applications (only for providing its filesystem to DispVMs), whereas work is intended to do both. In other words, the functional difference between TemplateVMs and AppVMs (as currently defined) still matters.

[andrewdavidwong]

I note your assumption that dvm has to be an acronym.

It's not really an assumption; just an observation that, historically, "DVM" originated as an acronym for "Disposable Virtual Machine."

imo the current implementation isn't confusing

I didn't mean to denigrate the implementation. It's confusing because we lack a distinct concept and term for the "in-between template," but that's okay, because that's precisely what we're now hashing out.

and as we move to the new implementation, ALL AppVMs will be able to provide read-only copies of the file system. Will that make them TemplateVMs? God forbid. That is why this issue isn't "orthogonal".

According to our current definition of "TemplateVM,", yes. Now, the question is, how should we update this definition in light of the new functionality? Currently, "TemplateVM" (and, less formally, "template") denotes two things:

• A VM that provides its filesystem in read-only mode to other VMs.
• A VM that is not intended for running applications, only for installing them.

With the new functionality, these two things can be separated for the first time. So, we have to decide which one of them (if either) "template" will continue to apply to. It could go either way, but my impression is that the first thing (providing a read-only filesystem) is more strongly associated with "template." If we go with this, we would say things like, "In 4.0, AppVMs can now serve as templates for DispVMs." In that case, we should also come up with a term to refer to the other thing (a VM not intended only for installing apps, not running them). Perhaps a modifier like "base," as in "base template," would work here.

On the other hand, there would be an advantage to reserving "TemplateVM" to denote only the latter thing (a VM intended only for installing apps, not running them) insofar as it would allow us to formalize the "parent/child" terminology that has occasionally been used to describe the relationship between TemplateVMs and TemplateBasedVMs. This parent/child analogy is even more appropriate now that it's possible for many "children" to become "parents" with "children" of their own. If we go this route, we could say something like:

ParentVM: Any VM that provides its filesystem (in part or in whole) in read-only mode to a ChildVM.
ChildVM: Any VM that receives its filesystem (in part or in whole) in read-only mode from a ParentVM.

(The disadvantage of these definitions is that they don't distinguish between providing only the root filesystem, as TemplateVMs currently do, and providing the entire filesystem, as "DVM (Templates)" currently do.)

In context of terminology, the new implementation is the same: there is still an AppVM like ...-dvm, which is a sort of template for Disposable VM. The only difference is that user may have multiple such "sort of templates". And theoretically -dvm suffix is no longer required (but for the sake of clarity we may artificially enforce it).

I mostly agree, but there is one important difference: While fedora-24-dvm and work can both serve as "sort-of templates" for DispVMs, fedora-24-dvm is not intended for running applications (only for providing its filesystem to DispVMs), whereas work is intended to do both. In other words, the functional difference between TemplateVMs and AppVMs (as currently defined) still matters.

[marmarek]

I mostly agree, but there is one important difference: While `fedora-24-dvm` and `work` can both serve as "sort-of templates" for DispVMs, `fedora-24-dvm` is not intended for running applications (only for providing its filesystem to DispVMs), whereas `work` is intended to do both. In other words, the functional difference between TemplateVMs and AppVMs (as currently defined) still matters.

I think the important thing is: where you keep your data. IMO the VM where you keep your data should _not_ be used as a template for DispVM. Or maybe I don't see some use cases for this?

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[marmarek]

I mostly agree, but there is one important difference: While `fedora-24-dvm` and `work` can both serve as "sort-of templates" for DispVMs, `fedora-24-dvm` is not intended for running applications (only for providing its filesystem to DispVMs), whereas `work` is intended to do both. In other words, the functional difference between TemplateVMs and AppVMs (as currently defined) still matters.

I think the important thing is: where you keep your data. IMO the VM where you keep your data should _not_ be used as a template for DispVM. Or maybe I don't see some use cases for this?

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[andrewdavidwong]

I think the important thing is: where you keep your data. IMO the VM where you keep your data should not be used as a template for DispVM. Or maybe I don't see some use cases for this?

There could be use cases for that, perhaps less common ones. For example, I may have some information that I want to publish, but I'm worried about an attack that attempts to alter my source data. (Basically, any case where my concern is integrity, not confidentiality.)

[andrewdavidwong]

I think the important thing is: where you keep your data. IMO the VM where you keep your data should not be used as a template for DispVM. Or maybe I don't see some use cases for this?

There could be use cases for that, perhaps less common ones. For example, I may have some information that I want to publish, but I'm worried about an attack that attempts to alter my source data. (Basically, any case where my concern is integrity, not confidentiality.)

[andrewdavidwong]

For example, I may have some information that I want to publish, but I'm worried about an attack that attempts to alter my source data.

Though I suppose in this case you could instead qvm-copy the data to a PublishVM.

[andrewdavidwong]

For example, I may have some information that I want to publish, but I'm worried about an attack that attempts to alter my source data.

Though I suppose in this case you could instead qvm-copy the data to a PublishVM.

[andrewdavidwong]

I've encountered a situation where I need to link to this term in the glossary, so I'm adding "DVM Template" to the glossary.

[andrewdavidwong]

I've encountered a situation where I need to link to this term in the glossary, so I'm adding "DVM Template" to the glossary.

[andrewdavidwong]

I think the important thing is: where you keep your data. IMO the VM where you keep your data should not be used as a template for DispVM. Or maybe I don't see some use cases for this?

There could be use cases for that, perhaps less common ones. For example, I may have some information that I want to publish, but I'm worried about an attack that attempts to alter my source data. (Basically, any case where my concern is integrity, not confidentiality.)

Possible use case: You have a trusted copy of the Bitcoin blockchain in a VM, and you want to use it for various untrusted activities. Howver, you're concerned that the untrusted activities might compromise your copy of the blockchain. Starting that VM as a DispVM is a nice solution.

[andrewdavidwong]

I think the important thing is: where you keep your data. IMO the VM where you keep your data should not be used as a template for DispVM. Or maybe I don't see some use cases for this?

There could be use cases for that, perhaps less common ones. For example, I may have some information that I want to publish, but I'm worried about an attack that attempts to alter my source data. (Basically, any case where my concern is integrity, not confidentiality.)

Possible use case: You have a trusted copy of the Bitcoin blockchain in a VM, and you want to use it for various untrusted activities. Howver, you're concerned that the untrusted activities might compromise your copy of the blockchain. Starting that VM as a DispVM is a nice solution.

[andrewdavidwong]

(The blockchain is too large to conveniently qvm-copy.)

[andrewdavidwong]

(The blockchain is too large to conveniently qvm-copy.)