Clarify DispVM related terminology and properties

[marmarek]

I see two problems:

1. Current DispVM related terminology is confusing
2. (as a proof of the above) we use it inconsistently

Terms:

• DispVM is a short from DisposableVM - this is actual Disposable VM, the thing that do not have any persistent storage; this actually should be changed to full DisposableVM
• DVM Template - is a TemplateBasedVM (which is going to change with GUI: use an standalone HVM as a DVM Template #4670) which can be a template for DispVM. Currently marked with template_for_dispvms=True property

I think DVM Template is too different from DispVM, it isn't immediately obvious that those two are related. It may be enough to stop using abbreviation here and name it DispVM Template, or even DisposableVM Template

Properties:

• template_for_dispvms - the knob turning a VM into DVM Template
• default_dispvm - contrary to its name, it points at DVM Template to be used by default; this is IMO the biggest problem here; this property can be set on both VMs and globally; global one is a default value for VMs

VM Settings GUI follows the same problem as we have with default_dispvm.

[marmarek]

I think we should:

• rename DispVM class to DisposableVM
• use DisposableVM Template, instead of DVM Template
• rename default_dispvm property to default_dispvm_template (and similarly adjust VM settings GUI).

There is also @dispvm and @dispvm:dvm-template qrexec policy syntax. I think this is less of a problem, as @dispvm means "create new DispVM", so @dispvm:dvm-template isn't that bad for "create new DispVM from specific DVM Template". Also, qrexec policy isn't exactly basic user facing thing, so an abbreviation here may be tolerable.

cc @andrewdavidwong @marmarta

[andrewdavidwong]

Related: #2486

[marmarek]

Outcome from F2F discussion with @marmarta and re-reading #2486:

• DispVM -> DisposableVM is ok, definitely at GUI level, possibly at command line and/or internal too
• DVM Template is bad, DisposableVM Template is too similar to TemplateVM (especially when DisposableVM Template in most cases is not TemplateVM), but we don't have any better idea; unless someone come up with a better idea, we'll use DisposableVM Template:
  • "Is DisposableVM Template" checkbox in settings in place of "Allow starting DisposableVMs from this qube"
  • "Default DisposableVM Template" drop down instead of "Default DispVM"
  • "default_disposablevm_template" property instead of "default_dispvm" (unsure about this point)
• all those settings should get tooltips with explanation

[andrewdavidwong]

"Is DisposableVM Template" checkbox in settings in place of "Allow starting DisposableVMs from this qube"

Minor suggestion: DisposableVM Template instead of Is DisposableVM Template. the Is sounds odd and unnecessary, IMHO.

"Default DisposableVM Template" drop down instead of "Default DispVM"

🙏

"default_disposablevm_template" property instead of "default_dispvm" (unsure about this point)

I'm in favor of it insofar as default_dispvm is highly misleading.

all those settings should get tooltips with explanation

🎉

[marmarta]

Alright, wonderful, we have a decent consensus! (and I think we'll defer to @andrewdavidwong's authority on the DisposableVM Template vs Is DisposableVM Template, as the native English speaker :) ) @marmarek, should I wait for changes in the property or make and push a cosmetic change to GUI tools already?

[marmarta]

I've made a pull request for this [renames+tooltips] ( QubesOS/qubes-manager#186 ) ; it would be awesome if someone with better English could take a look at my grammar (@andrewdavidwong , if you'd have a moment, it would be great).

[andrewdavidwong]

I've made a pull request for this [renames+tooltips] ( QubesOS/qubes-manager#186 ) ; it would be awesome if someone with better English could take a look at my grammar (@andrewdavidwong , if you'd have a moment, it would be great).

Will do!

[andrewdavidwong]

I've made a pull request for this [renames+tooltips] ( QubesOS/qubes-manager#186 ) ; it would be awesome if someone with better English could take a look at my grammar (@andrewdavidwong , if you'd have a moment, it would be great).

Will do!

Added some comments on QubesOS/qubes-manager#186. Thanks for doing this!

[qubesos-bot]

Automated announcement from builder-github

The package qubes-manager-4.0.37-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-manager-4.0.37-1.fc29 has been pushed to the r4.1 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-manager-4.0.39-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[andrewdavidwong]

@ninavizz is saying that "DisposableVM" is too long to use in UIs (#4723 (comment)).

To recap:

• "DispVM" gets confused with "DisplayVM"
• "DVM" is open to even more ambiguity than "DispVM"
• "DisposableVM" is too long in UIs

If "DispVM" would be perfect but for the ambiguity with "display," then why not just name it "TempVM" (or "TempQube," depending on the outcome of #1015)? As far as I can tell, there's no nearby word that starts with "temp" that would lead to similar confusion, and "temp" is already a familiar shortened form of "temporary."

[DemiMarie]

@ninavizz suggested “DQube” in #4723 (comment), which I support. @ninavizz would you mind reposting that comment here?

[andrewdavidwong]

@DemiMarie, you can just quote the comment and link to it, like this:

@ninavizz wrote in #4723 (comment):

Oh! DQube for Disp-VM. Using the qube nomenclature in an easy-to-remember fashion, and very easy to say (which is a good indication towards cognitive processes)! "Disposable Qube" in written documentation, always written-out in the first sentence of contextual help as "Disposable Qube (DQube)"

There's only one sys-graphics qube with that GUI isolation schema, so no need to go to GQube or 0Qube for dom0 or sys-graphics... is that correct?

I'm not sure why, but "DQube" sounds like a joke term to me (in the sense of sounding satirical). Maybe it's due to the similarity to slang terms like "d-bag" or the possibility that it could be pronounced "da qube." It also sounds like it could be the name of a frosty new Dairy Queen treat.

In any case, it's just "DVM" with the "VM" -> "qube" substitution. It still has the ambiguity that the "D" could stand for any word that starts with "D." People don't read the documentation. If explaining the abbreviation in the documentation were sufficient, then we would have never had a reason to move away from "DispVM" in the first place, because no one would have been confused, because they all would have known that "Disp" is short for "Disposable" from reading it in the documentation. 🙃

[brendanhoar]

If "DispVM" would be perfect but for the ambiguity with "display," then why not just name it "TempVM" (or "TempQube," depending on the outcome of #1015)? As far as I can tell, there's no nearby word that starts with "temp" that would lead to similar confusion, and "temp" is already a familiar shortened form of "temporary."

Template VM

:(

B

[andrewdavidwong]

If "DispVM" would be perfect but for the ambiguity with "display," then why not just name it "TempVM" (or "TempQube," depending on the outcome of #1015)? As far as I can tell, there's no nearby word that starts with "temp" that would lead to similar confusion, and "temp" is already a familiar shortened form of "temporary."

Template VM

:(

B

Ah, indeed. I had a feeling, as I was writing that, that there would turn out to be a blindingly obvious case that wasn't occurring to me. 😆

It now also occurs to me that using any single letter precludes us from reusing that letter for any new type of qube we might introduce in the future. For example, if we ever introduce a new type of qube based any of the following, "d" would already be taken: "display," "data," "database," "decryption," "default," "desktop," "development," "device," "disc," "disk," "distributed," "documentation," "download," "drive," "dynamic," or "Debian" (oops, too late for this one).

[DemiMarie]

What about Transient?

[andrewdavidwong]

What about Transient?

But "TransientQube" would still be too long in UIs, so it would have to be shortened, presumably to "TransVM / TransQube"?

People might read it as the prefix "trans-" (as in the words "transatlantic," "transgender," etc.).

Since we already have a long and established history with "DispVM" and "DVM," we might as well just pick one and stick with it. Sure, a few people might think it's "DisplayVM," but that will happen with any sufficiently-short term, including "DQube," which could just as easily mean "DisplayQube."

[SvenSemmler]

I would like to challenge the "too long"/"cognitive friction" argument in this context. Obviously very long labels are bad, but ambiguous ones aren't good either. "Disposable Qube" is not that long and it's meaning is clear. I played with "one time", "temporary" and "ephemeral" but in general we refer to something as "disposable" if it's meant to be used once and then thrown away, which describes this kind of qube perfectly. Most of the other proposals discussed might be a few characters shorter but introduce ambiguity as this and other threads demonstrate. In the GUI I think it would also work better to write them as two words instead of one ("Disposable Qube" rather than "DisposableQube"). The user is not a programmer in most cases. For CLI arguments I don't see why "VM" or "Qube" would be needed at all: i.e. qvm-create --class=Template --class=Application --class=Disposable --class=Standalone What term is used in code is (I hope) irrelevant for this discussion. When it comes to the UI and CLI however it would make sense to use Qube as the OS is called Qubes OS after all. Also in some version of the future a Qube might no longer technically be a VM but still act and fulfill the duties of a Qube. Hence it makes sense the the Qube mode currently is HVM, PVH or PV ...but that's the only place where that kind of detail should be exposed to the user in my opinion.

[unman]

On Thu, May 13, 2021 at 08:45:37AM -0700, Sven Semmler wrote: I would like to challenge the "too long"/"cognitive friction" argument in this context. Obviously very long labels are bad, but ambiguous ones aren't good either. "Disposable Qube" is not that long and it's meaning is clear. I played with "one time", "temporary" and "ephemeral" but in general we refer to something as "disposable" if it's meant to be used once and then thrown away, which describes this kind of qube perfectly. Most of the other proposals discussed might be a few characters shorter but introduce ambiguity as this and other threads demonstrate. In the GUI I think it would also work better to write them as two words instead of one ("Disposable Qube" rather than "DisposableQube"). The user is not a programmer in most cases. For CLI arguments I don't see why "VM" or "Qube" would be needed at all: i.e. qvm-create --class=Template --class=Application --class=Disposable --class=Standalone What term is used in code is (I hope) irrelevant for this discussion. When it comes to the UI and CLI however it would make sense to use Qube as the OS is called Qubes OS after all. Also in some version of the future a Qube might no longer technically be a VM but still act and fulfill the duties of a Qube. Hence it makes sense the the Qube mode currently is HVM, PVH or PV ...but that's the only place where that kind of detail should be exposed to the user in my opinion.

I agree with the sentiments here. I'm not a user of the Qube Manager, but I know that it already has labels like "Disposable VM Template", and no one has complained about them to me. If people understand what a disposableVM (disposable qube) is, then it makes sense to see that in the interface. I should say that when I set up custom menus for beginners, I don't use "Domain", "disposableVM" etc. at all, but then I try to move emphasis away from the implementation. I include menu entries like "Single Use Browser", and users seem to get that more readily than when I used "disposable".

[andrewdavidwong]

When it comes to the UI and CLI however it would make sense to use Qube
as the OS is called Qubes OS after all. Also in some version of the
future a Qube might no longer technically be a VM but still act and
fulfill the duties of a Qube.

That would be "qube," not "Qube." This is the wrong issue for that topic. Please see #1015 instead. Please be aware that you are repeating points that were made in comments on that issue years ago.

I agree with the sentiments here.
I'm not a user of the Qube Manager, but I know that it already has
labels like "Disposable VM Template", and no one has complained about
them to me.

That would be "DisposableVM Template."

If people understand what a disposableVM (disposable qube)
is, then it makes sense to see that in the interface.

That would be "DisposableVM."

---

These renaming topics are quite possibly the greatest bike shed in the history of the Qubes OS Project, and I have come to the conclusion that raising them in the first place was a grave mistake. We have literally gone in circles for years on this, wasting countless hours. For the sake of my sanity, let us please be done with this.

[ninavizz]

@andrewdavidwong How features are named, is a major, major component of UX. I appreciate the team has gone in circles over these things for years, however I am asking you to please appreciate the necessity of including naming as a consideration in the work I am doing.

The mental-model created by what you explain above, between the two forms of a disposable VM, is confusing and conflicting. Hence, I feel needs to be improved upon. To do that, I need more clarity via a synchronous activity, to make an informed recommendation.

FWIW, attempting to find resolution on the naming of features in isolated GH Issues, I also feel is also ripe to blossom into a bikeshed to bikeshed all bikeshed discussions. I am very with you in not wanting to build more bikesheds... but I believe the medium for this discussion (a ticketing system created to support people writing code), is much of the problem.

[andrewdavidwong]

@andrewdavidwong How features are named, is a major, major component of UX. I appreciate the team has gone in circles over these things for years, however I am asking you to please appreciate the necessity of including naming as a consideration in the work I am doing.

The mental-model created by what you explain above, between the two forms of a disposable VM, is confusing and conflicting. Hence, I feel needs to be improved upon. To do that, I need more clarity via a synchronous activity, to make an informed recommendation.

FWIW, attempting to find resolution on the naming of features in isolated GH Issues, I also feel is also ripe to blossom into a bikeshed to bikeshed all bikeshed discussions. I am very with you in not wanting to build more bikesheds... but I believe the medium for this discussion (a ticketing system created to support people writing code), is much of the problem.

Fair enough, so let's discontinue any further discussion/bikeshedding in this issue, have the synchronous activity to reach a firm decision, then post the outcome here so that action can be taken. Sound good?

[ninavizz]

Fair enough, so let's discontinue any further discussion/bikeshedding in this issue, have the synchronous activity to reach a firm decision, then post the outcome here so that action can be taken. Sound good?

Totally! Tho to be as inclusive as possible, I'd also like to post an invitation here for anyone desiring to contribute a synchronous activity, at least a week in advance—so we don't inadvertently exclude anybody.

[andrewdavidwong]

Tho to be as inclusive as possible, I'd also like to post an invitation here for anyone desiring to contribute a synchronous activity, at least a week in advance—so we don't inadvertently exclude anybody.

Sure, I figured as much. Coordinating the activity doesn't count as discussion/bikeshedding. 🙂