Consider changing "AppVM" to "qube" for better UX

[bnvk]

I'm not sure if this is the right place to file what I consider UX bugs / improvements- if it's not, please tell me where else to do so :-)

I propose changing the root VM currently called dom0 to be called qubes as I wager it would be considerably more user friendly in testing. My reasoning is:

• It is less technical and jargony
• Does not introduce a new term a user must understand / remember
• Makes more logical sense "I installed Qubes OS on my computer, thus qubes is the main domain"

[marmarek]

I don't think this is good idea to name it qubes, because it can be
ambiguous. It will be even worse when we implement GUI VM (current
dom0 will be unaccessible to the user directly then). But we are
slowly moving to name AdminVM (currently you can see it as a type for
dom0).

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 don't think this is good idea to name it qubes, because it can be
ambiguous. It will be even worse when we implement GUI VM (current
dom0 will be unaccessible to the user directly then). But we are
slowly moving to name AdminVM (currently you can see it as a type for
dom0).

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 Brennan's heart is the right place, but I have to agree with Marek. To elaborate:

1. a. "Qubes OS" refers to the entire OS, which includes Xen, dom0, and multiple domUs. If we start also referring to dom0 as "Qubes," then the term "Qubes" will be ambiguous between the whole OS and a single VM inside that OS.

   b. Joanna makes a distinction between "Qubes OS" and "Qubes." As I understand this distinction, "Qubes OS" refers to the whole OS which we currently have, while "Qubes" simpliciter refers to the Hypervisor Abstraction Layer (HAL), which is not by itself a complete OS.

2. Once dom0 is bifurcated into the GUIVM and the AdminVM, there will not be a compelling reason to refer to only one of these VMs as "Qubes" instead of the other, and it would be strange to refer to both of them as "Qubes," since then someone could say, "I'm having a problem in Qubes," and there will be three(!) different things they could be referring to.

[andrewdavidwong]

I think Brennan's heart is the right place, but I have to agree with Marek. To elaborate:

1. a. "Qubes OS" refers to the entire OS, which includes Xen, dom0, and multiple domUs. If we start also referring to dom0 as "Qubes," then the term "Qubes" will be ambiguous between the whole OS and a single VM inside that OS.

   b. Joanna makes a distinction between "Qubes OS" and "Qubes." As I understand this distinction, "Qubes OS" refers to the whole OS which we currently have, while "Qubes" simpliciter refers to the Hypervisor Abstraction Layer (HAL), which is not by itself a complete OS.

2. Once dom0 is bifurcated into the GUIVM and the AdminVM, there will not be a compelling reason to refer to only one of these VMs as "Qubes" instead of the other, and it would be strange to refer to both of them as "Qubes," since then someone could say, "I'm having a problem in Qubes," and there will be three(!) different things they could be referring to.

[mfc]

sounds like we have agreement that it should be admin?

the thrust of this ticket is to change from dom0 which has no meaning to users and is a confusing term. There have been more recent in-person discussions about this with brennan, joanna and I think we all agree qubes is not the right term since that will be the future name for AppVMs most likely.

[mfc]

sounds like we have agreement that it should be admin?

the thrust of this ticket is to change from dom0 which has no meaning to users and is a confusing term. There have been more recent in-person discussions about this with brennan, joanna and I think we all agree qubes is not the right term since that will be the future name for AppVMs most likely.

[bnvk]

I definitely think admin is an improvement over dom0 and per our in person chats... I think @mfc is referring to what we discussed at the usability work session at the OTF Summit, which was calling VMs in general a qube and in this specific case it would be the admin qube which seems pretty logical and decently intuitive!

[bnvk]

I definitely think admin is an improvement over dom0 and per our in person chats... I think @mfc is referring to what we discussed at the usability work session at the OTF Summit, which was calling VMs in general a qube and in this specific case it would be the admin qube which seems pretty logical and decently intuitive!

[marmarek]

I don't think calling 'VM' a 'qube' is a good idea - this would make
virtually any non-Qubes documentation useless on Qubes...

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 don't think calling 'VM' a 'qube' is a good idea - this would make
virtually any non-Qubes documentation useless on Qubes...

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?

[adrelanos]

Marek Marczykowski-Górecki:

I don't think calling 'VM' a 'qube' is a good idea - this would make
virtually any non-Qubes documentation useless on Qubes...

I agree. I don't think this kind of complexity (term: VM) can be hidden.
We'd still explain somewhere, that a qube is a VM. So we wouldn't reduce
complexity, but add another term on top, qube. And thereby increasing
complexity.

[adrelanos]

Marek Marczykowski-Górecki:

I don't think calling 'VM' a 'qube' is a good idea - this would make
virtually any non-Qubes documentation useless on Qubes...

I agree. I don't think this kind of complexity (term: VM) can be hidden.
We'd still explain somewhere, that a qube is a VM. So we wouldn't reduce
complexity, but add another term on top, qube. And thereby increasing
complexity.

[bnvk]

The concept of "qube" instead of "VM" was workshopped between
@mfc @rootkovska myself, and the SimplySecure team in DC. There
seemed a pretty unanimous agreement that it had the potential for
far more user friendly outcomes and that we could get much
mileage with icons, interface elements, and user friendly
storytelling.

Joanna, back this up here please, otherwise I'll drop the concept
(and stop working it into my website designs) and you all can
skip the rest of this and go on with your day :-)

this would make virtually any non-Qubes documentation useless on Qubes...

If you mean documentation on other projects, websites, etc. which
explain how VMs work- not necessarily. As long as we have short
sentences (throughout our docs) explaining "a qube is just a user
friendly term to represent a VM" I'd wager technical users who
like understanding what a VM actually is can handle one simple
metaphor.

I agree. I don't think this kind of complexity (term: VM) can be hidden... So we wouldn't reduce complexity, but add another term on top, qube. And thereby increasing complexity.

I think that's a fundamentally wrong assumption from a highly
technical user's POV. It can totally be hidden from
non-technical users. A VM does not need to be explained in the UI
via button names, terms, etc. Normal users will never need to
read / nor try to understand that a "qube" actually is a "VM"

Normal users never need to learn when they "connect to the
internet" or "go on the web" they are actually "making a TCP/IP
connection using the HTTP protocol to interact with to a
webserver". Or when they "access a website securely" they are
actually "doing public / private key cryptography using SSL /
TLS certificates." Yes, this admittedly dumbs things down, which
is entirely the point- it is essential for achieving a simple
"out of the box" UX for non-technical users. As long as honest
documentation & easy access to that technical information exists
for the curious / more technical, I don't see a problem here.

We have to think in terms of initial first impression of a user
when thinking of usability. Given the majority of users are
non-technical, is the term & concept of a "VM" helpful to anyone
if they don't already understand what a VM is? Would a user who's
never heard the term VM understand what a VM is? Furthermore,
would it make sense in the Qubes context after reading one to two
sentences? Almost certainly not. Therefore, eliminate jargon &
complexity and go for simple metaphors and try.

[bnvk]

The concept of "qube" instead of "VM" was workshopped between
@mfc @rootkovska myself, and the SimplySecure team in DC. There
seemed a pretty unanimous agreement that it had the potential for
far more user friendly outcomes and that we could get much
mileage with icons, interface elements, and user friendly
storytelling.

Joanna, back this up here please, otherwise I'll drop the concept
(and stop working it into my website designs) and you all can
skip the rest of this and go on with your day :-)

this would make virtually any non-Qubes documentation useless on Qubes...

If you mean documentation on other projects, websites, etc. which
explain how VMs work- not necessarily. As long as we have short
sentences (throughout our docs) explaining "a qube is just a user
friendly term to represent a VM" I'd wager technical users who
like understanding what a VM actually is can handle one simple
metaphor.

I agree. I don't think this kind of complexity (term: VM) can be hidden... So we wouldn't reduce complexity, but add another term on top, qube. And thereby increasing complexity.

I think that's a fundamentally wrong assumption from a highly
technical user's POV. It can totally be hidden from
non-technical users. A VM does not need to be explained in the UI
via button names, terms, etc. Normal users will never need to
read / nor try to understand that a "qube" actually is a "VM"

Normal users never need to learn when they "connect to the
internet" or "go on the web" they are actually "making a TCP/IP
connection using the HTTP protocol to interact with to a
webserver". Or when they "access a website securely" they are
actually "doing public / private key cryptography using SSL /
TLS certificates." Yes, this admittedly dumbs things down, which
is entirely the point- it is essential for achieving a simple
"out of the box" UX for non-technical users. As long as honest
documentation & easy access to that technical information exists
for the curious / more technical, I don't see a problem here.

We have to think in terms of initial first impression of a user
when thinking of usability. Given the majority of users are
non-technical, is the term & concept of a "VM" helpful to anyone
if they don't already understand what a VM is? Would a user who's
never heard the term VM understand what a VM is? Furthermore,
would it make sense in the Qubes context after reading one to two
sentences? Almost certainly not. Therefore, eliminate jargon &
complexity and go for simple metaphors and try.

[mfc]

this would make virtually any non-Qubes documentation useless on Qubes...

I don't think non-technical users use non-Qubes documentation for Qubes, and there shouldn't be an expectation that they do so. Qubes documentation should be comprehensive for non-technical users.

We'd still explain somewhere, that a qube is a VM.

As long as we have short sentences (throughout our docs) explaining "a qube is just a user friendly term to represent a VM"

yep agreed. it would drastically increase the usefulness of the Qubes name & brand in explaining how Qubes works to non-technical users.

[mfc]

this would make virtually any non-Qubes documentation useless on Qubes...

I don't think non-technical users use non-Qubes documentation for Qubes, and there shouldn't be an expectation that they do so. Qubes documentation should be comprehensive for non-technical users.

We'd still explain somewhere, that a qube is a VM.

As long as we have short sentences (throughout our docs) explaining "a qube is just a user friendly term to represent a VM"

yep agreed. it would drastically increase the usefulness of the Qubes name & brand in explaining how Qubes works to non-technical users.

[woju]

On Tue, Nov 10, 2015 at 10:35:30AM -0800, Michael Carbone wrote:

As long as we have short sentences (throughout our docs) explaining
"a qube is just a user friendly term to represent a VM"

Maybe we could settle on the term „domain” which is both more
user-friendly than „VM” and already established in literature, most
importantly (and prominently) in libvirt, which we use.

[woju]

On Tue, Nov 10, 2015 at 10:35:30AM -0800, Michael Carbone wrote:

As long as we have short sentences (throughout our docs) explaining
"a qube is just a user friendly term to represent a VM"

Maybe we could settle on the term „domain” which is both more
user-friendly than „VM” and already established in literature, most
importantly (and prominently) in libvirt, which we use.

[bnvk]

Maybe we could settle on the term „domain” which is both more

I think that word is already a bit understood by the general
public to represent websites- e.g. "domain names" and even then,
is bit ephemeral / abstract.

...and already established in literature, most importantly (and prominently) in libvirt

If we try to make our UI naming conventions match things in the
literature, we are bound to end up with things that make sense to
technical users who've read "the literature" probably at the
expense of those who have not :-)

[bnvk]

Maybe we could settle on the term „domain” which is both more

I think that word is already a bit understood by the general
public to represent websites- e.g. "domain names" and even then,
is bit ephemeral / abstract.

...and already established in literature, most importantly (and prominently) in libvirt

If we try to make our UI naming conventions match things in the
literature, we are bound to end up with things that make sense to
technical users who've read "the literature" probably at the
expense of those who have not :-)

[andrewdavidwong]

When I first encountered Qubes and saw the Qubes logo (a stack of three cubes, at the time), it was fairly obvious that "Qubes" was a unique spelling of "cubes," and that the "cubes" represented VMs. For this reason, I found it strange that nothing in Qubes was ever referred to as a "qube."

However, if the primary reason to start referring to VMs as "qubes" now is that the OS is already named "Qubes OS" and has had that name for many years, then this strikes me as a rather weak reason. There should be some compelling, independent reason to introduce a new term which abstracts away from VMs.

Here's one potential reason: In Qubes, there are important distinctions between different types of VMs. For example, TemplateVMs are typically more trusted than most of their child TemplateBasedVMs, and the compromise of a TemplateVM is generally (but not always) a worse outcome. We also have StandaloneVMs and HVMs, the latter of which can themselves be either TemplateVMs or StandaloneVMs. There are also ProxyVMs and NetVMs, which are typically less trusted than other types of VMs (but not always, e.g., TorVMs). Finally, we use the term "AppVM" to refer primarily to TemplateBasedVMs, but sometimes also to other types (rather ambiguously, unfortunately).

Given this complex situation, the term "qube" might be most helpful if it were used to refer only to a proper subset of these different types of VMs, namely the ones with which less technical users would primarily interact. For example, we might say:

A qube is where you do your work and store your files.
Qubes OS lets you compartmentalize your digital life into securely isolated qubes.

So, a "qube" would refer to most AppVMs, StandaloneVMs, (non-template) HVMs, TemplateBasedVMs, etc. Meanwhile, things like TemplateVMs, ProxyVMs, NetVMs, and dom0 would not be referred to as "qubes." Instead, these would be made less visible to less technical users in order to protect them from making common but fundamental mistakes (like trying to do work in a TemplateVM or in dom0).

(Note that this is just a provisional idea, not a finalized recommendation. My aim is to point out that there are more useful ways to leverage a term of abstraction like "qube" rather than as a 1:1 replacement for "VM.")

[andrewdavidwong]

When I first encountered Qubes and saw the Qubes logo (a stack of three cubes, at the time), it was fairly obvious that "Qubes" was a unique spelling of "cubes," and that the "cubes" represented VMs. For this reason, I found it strange that nothing in Qubes was ever referred to as a "qube."

However, if the primary reason to start referring to VMs as "qubes" now is that the OS is already named "Qubes OS" and has had that name for many years, then this strikes me as a rather weak reason. There should be some compelling, independent reason to introduce a new term which abstracts away from VMs.

Here's one potential reason: In Qubes, there are important distinctions between different types of VMs. For example, TemplateVMs are typically more trusted than most of their child TemplateBasedVMs, and the compromise of a TemplateVM is generally (but not always) a worse outcome. We also have StandaloneVMs and HVMs, the latter of which can themselves be either TemplateVMs or StandaloneVMs. There are also ProxyVMs and NetVMs, which are typically less trusted than other types of VMs (but not always, e.g., TorVMs). Finally, we use the term "AppVM" to refer primarily to TemplateBasedVMs, but sometimes also to other types (rather ambiguously, unfortunately).

Given this complex situation, the term "qube" might be most helpful if it were used to refer only to a proper subset of these different types of VMs, namely the ones with which less technical users would primarily interact. For example, we might say:

A qube is where you do your work and store your files.
Qubes OS lets you compartmentalize your digital life into securely isolated qubes.

So, a "qube" would refer to most AppVMs, StandaloneVMs, (non-template) HVMs, TemplateBasedVMs, etc. Meanwhile, things like TemplateVMs, ProxyVMs, NetVMs, and dom0 would not be referred to as "qubes." Instead, these would be made less visible to less technical users in order to protect them from making common but fundamental mistakes (like trying to do work in a TemplateVM or in dom0).

(Note that this is just a provisional idea, not a finalized recommendation. My aim is to point out that there are more useful ways to leverage a term of abstraction like "qube" rather than as a 1:1 replacement for "VM.")

[mfc]

When I first encountered Qubes and saw the Qubes logo (a stack of three cubes, at the time), it was fairly obvious that "Qubes" was a unique spelling of "cubes," and that the "cubes" represented VMs. For this reason, I found it strange that nothing in Qubes was ever referred to as a "qube."

yep same here.

So, a "qube" would refer to most AppVMs, StandaloneVMs, (non-template) HVMs, TemplateBasedVMs, etc. Meanwhile, things like TemplateVMs, ProxyVMs, NetVMs, and dom0 would not be referred to as "qubes." Instead, these would be made less visible to less technical users in order to protect them from making common but fundamental mistakes (like trying to do work in a TemplateVM or in dom0).

yes exactly, agreed.

this is what brennan, joanna, and myself had discussed in DC - at the most basic level, that AppVMs are qubes, while everything else ("service VMs" = proxyvm, netvm, dom0) is not.

I don't think non-technical users will be using StandaloneVMs, HVMs, etc.

[mfc]

When I first encountered Qubes and saw the Qubes logo (a stack of three cubes, at the time), it was fairly obvious that "Qubes" was a unique spelling of "cubes," and that the "cubes" represented VMs. For this reason, I found it strange that nothing in Qubes was ever referred to as a "qube."

yep same here.

So, a "qube" would refer to most AppVMs, StandaloneVMs, (non-template) HVMs, TemplateBasedVMs, etc. Meanwhile, things like TemplateVMs, ProxyVMs, NetVMs, and dom0 would not be referred to as "qubes." Instead, these would be made less visible to less technical users in order to protect them from making common but fundamental mistakes (like trying to do work in a TemplateVM or in dom0).

yes exactly, agreed.

this is what brennan, joanna, and myself had discussed in DC - at the most basic level, that AppVMs are qubes, while everything else ("service VMs" = proxyvm, netvm, dom0) is not.

I don't think non-technical users will be using StandaloneVMs, HVMs, etc.

[rootkovska]

So, I think I still like the "VM" most, b/c it's shortest and also (for the slightly more technical crowd) immediately explains how the isolation is being done.

As for dom0 renaming -- we definately need to do that: not only is "Dom0" meaningless to most people, but also given Qubes HAL architecture it's too Xen-specific. I suggest to replace it with AdminVM, or just Admin (or 'admin' depending what looks nicer). In the future (Qubes 4) we will also have GUI domain, which should also be listed in the manager.

[rootkovska]

So, I think I still like the "VM" most, b/c it's shortest and also (for the slightly more technical crowd) immediately explains how the isolation is being done.

As for dom0 renaming -- we definately need to do that: not only is "Dom0" meaningless to most people, but also given Qubes HAL architecture it's too Xen-specific. I suggest to replace it with AdminVM, or just Admin (or 'admin' depending what looks nicer). In the future (Qubes 4) we will also have GUI domain, which should also be listed in the manager.

[adrelanos]

Michael Carbone:

I don't think non-technical users will be using StandaloneVMs, HVMs, TemplateBasedVMs, etc.

I think this was a mistake or a confusion about terms.

AppVMs can be one type of TemplateBasedVMs.

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

"Template-BasedVM Opposite of a Standalone(VM). A VM, that depends on
another TemplateVM for its root filesystem."

TemplateBasedVMs can be AppVMs, ProxyVMs, NetVMs, HVMs.

[adrelanos]

Michael Carbone:

I don't think non-technical users will be using StandaloneVMs, HVMs, TemplateBasedVMs, etc.

I think this was a mistake or a confusion about terms.

AppVMs can be one type of TemplateBasedVMs.

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

"Template-BasedVM Opposite of a Standalone(VM). A VM, that depends on
another TemplateVM for its root filesystem."

TemplateBasedVMs can be AppVMs, ProxyVMs, NetVMs, HVMs.

[mfc]

I think this was a mistake or a confusion about terms.

corrected in comment, thanks #1015 (comment)

[mfc]

I think this was a mistake or a confusion about terms.

corrected in comment, thanks #1015 (comment)

[bnvk]

AppVMs, ProxyVMs, NetVMs, etc... are great if the goal is make sense to technical people familiar with virtualization. It's taken me, a mid level web engineer (who's used normal VMs), months to understand / how to use them correctly in Qubes. I still don't understand what an HVM is.

VM... it's shortest and also (for the slightly more technical crowd) immediately explains how the isolation is being done.

At the expense of being meaningless to the non-technical crowd. VM is accurate, it's less likely to explain the underlying concepts via UI elements to those learning a new system (unless one first learns what a VM is), and has the side effect of increasing cognitive load for all new users. The general practice in design is to reduce cognitive load by going with simple and identifiable metaphors.

A cube is a visual symbol lots of people around the world learn at a young age- thus, "qube" and "Qubes" for the name of the OS was a stroke of brilliance, I think. I also found it odd to never see a mention of a "cube" while using Qubes.

All of these are reasons I say- start with a fresh user friendly metaphor that's simple to visualize, easy to remember, and matches our name. Here is some of the ideas I was thinking to help explain Qubes and what a VM / qube is:

Here is something that explains our upcoming concept of "recipes" or pre-configurations that plays onto that "qube" metaphor:

The above concepts that could be on the website, in a slideshow, or within a GUI setup guide in the OS.

there are more useful ways to leverage a term of abstraction like "qube" rather than as a 1:1 replacement for "VM.")

More on this in another issue at a later date :)

[bnvk]

AppVMs, ProxyVMs, NetVMs, etc... are great if the goal is make sense to technical people familiar with virtualization. It's taken me, a mid level web engineer (who's used normal VMs), months to understand / how to use them correctly in Qubes. I still don't understand what an HVM is.

VM... it's shortest and also (for the slightly more technical crowd) immediately explains how the isolation is being done.

At the expense of being meaningless to the non-technical crowd. VM is accurate, it's less likely to explain the underlying concepts via UI elements to those learning a new system (unless one first learns what a VM is), and has the side effect of increasing cognitive load for all new users. The general practice in design is to reduce cognitive load by going with simple and identifiable metaphors.

A cube is a visual symbol lots of people around the world learn at a young age- thus, "qube" and "Qubes" for the name of the OS was a stroke of brilliance, I think. I also found it odd to never see a mention of a "cube" while using Qubes.

All of these are reasons I say- start with a fresh user friendly metaphor that's simple to visualize, easy to remember, and matches our name. Here is some of the ideas I was thinking to help explain Qubes and what a VM / qube is:

Here is something that explains our upcoming concept of "recipes" or pre-configurations that plays onto that "qube" metaphor:

The above concepts that could be on the website, in a slideshow, or within a GUI setup guide in the OS.

there are more useful ways to leverage a term of abstraction like "qube" rather than as a 1:1 replacement for "VM.")

More on this in another issue at a later date :)

[andrewdavidwong]

@bnvk:

there are more useful ways to leverage a term of abstraction like "qube" rather than as a 1:1 replacement for "VM.")

More on this in another issue at a later date :)

I think you've misunderstood. This isn't "another issue." It has to do with the very definition of the term "qube" and the fundamental way that term is used. In fact, your post seems to presuppose the very point I was making.

@rootkovska:

So, I think I still like the "VM" most, b/c it's shortest and also (for the slightly more technical crowd) immediately explains how the isolation is being done.

This sounds like a response to the proposal of performing a 1:1 replacement of "VM" with "qube," but that was not the only proposal made. I pointed out that there are more useful ways to leverage a term of abstraction like "qube," e.g., by using it to refer only to a proper subset of the VMs in Qubes OS, such as the ones in which users are supposed to run programs and storing data.

[andrewdavidwong]

@bnvk:

there are more useful ways to leverage a term of abstraction like "qube" rather than as a 1:1 replacement for "VM.")

More on this in another issue at a later date :)

I think you've misunderstood. This isn't "another issue." It has to do with the very definition of the term "qube" and the fundamental way that term is used. In fact, your post seems to presuppose the very point I was making.

@rootkovska:

So, I think I still like the "VM" most, b/c it's shortest and also (for the slightly more technical crowd) immediately explains how the isolation is being done.

This sounds like a response to the proposal of performing a 1:1 replacement of "VM" with "qube," but that was not the only proposal made. I pointed out that there are more useful ways to leverage a term of abstraction like "qube," e.g., by using it to refer only to a proper subset of the VMs in Qubes OS, such as the ones in which users are supposed to run programs and storing data.

[unman]

It strikes me that there is a major disconnect here because it is not clear what the target audience is for Qubes, and therefore what terms are appropriate to adopt. (Perhaps I should say "not clear to me.")

I have no idea what the profile of current Qubes users is. If postings to qubes-users are any guide, they are pretty enthusiastic and cover all bases between complete novice with no prior linux experience and Dan Bernstein. Most of them are, I would say, "fiddlers", and don't read documentation or search for solutions.

AppVMs, ProxyVMs, NetVMs, etc... are great if the goal is make sense to technical people familiar with virtualization. It's taken me, a mid level web engineer (who's used normal VMs), months to understand / how to use them correctly in Qubes. I still don't understand what an HVM is.

I think this goes to the heart of the problem, although I'm quite surprised you found it so difficult. (HVM is pretty standard.) I would have thought that the solution was to improve documentation so that these terms are not so hard to understand. (Although this wont help people who wont read.)

But this is to make (technical) sense to (relatively) technical people, and you are trying to make a contribution at a technical level. You shouldn't need any of this to improve your security using Qubes.

Why is Bromium so neat? Because it's fast and there is no learning curve. A Windows user can just use it straight off.
I agree with @bnvk that detail can totally be hidden from non-technical users. But I don't think that the answer is to come up with new terms. It's to drastically simplify the offering (Is this what's implied in "recipes"?). Completely hide the implementation for those users.

I've been experimenting with a Torified Debian Qubes , with set VMs , and a single "standard" menu. No reference to VMs, no "domains" in the menu, no manager. Restricted applications running in the "email" and bank domain - all files are passed off to DispVMs for opening. Banking browser restricted to bank domains - this is the only thing that isn't easy to automate.
I don't have a mother to try it on, but I have given it to assorted folk, most completely non technical. The only complaints have been about browsing speed - that's Tor for you. Oh, and boot time. And that funny copy/paste thing. And slow boot times for VMs - not, of course, put in those terms. ( I mitigate that by prestarting standard VMs on login. ) And maybe some other minor stuff.
The point is that no explanation is required as long as it just works. And these are people who wouldn't find talk about VMs, recipes, qube(singular or plural) helpful. But they do want to be a little safer online.

Maybe that isn't the target?

The thing is that security is really difficult. You can improve security by educating people or by giving them tools to use, minimise the chances of misuse by enforcing use and taking away user choice. Once you let folk loose on the detail of the implementation then you had better hope they understand what they are doing and what the risks are: they wont unless they have some grasp of the technical background.
It's a moot point whether a terminology change will improve matters. I think not.

[unman]

It strikes me that there is a major disconnect here because it is not clear what the target audience is for Qubes, and therefore what terms are appropriate to adopt. (Perhaps I should say "not clear to me.")

I have no idea what the profile of current Qubes users is. If postings to qubes-users are any guide, they are pretty enthusiastic and cover all bases between complete novice with no prior linux experience and Dan Bernstein. Most of them are, I would say, "fiddlers", and don't read documentation or search for solutions.

AppVMs, ProxyVMs, NetVMs, etc... are great if the goal is make sense to technical people familiar with virtualization. It's taken me, a mid level web engineer (who's used normal VMs), months to understand / how to use them correctly in Qubes. I still don't understand what an HVM is.

I think this goes to the heart of the problem, although I'm quite surprised you found it so difficult. (HVM is pretty standard.) I would have thought that the solution was to improve documentation so that these terms are not so hard to understand. (Although this wont help people who wont read.)

But this is to make (technical) sense to (relatively) technical people, and you are trying to make a contribution at a technical level. You shouldn't need any of this to improve your security using Qubes.

Why is Bromium so neat? Because it's fast and there is no learning curve. A Windows user can just use it straight off.
I agree with @bnvk that detail can totally be hidden from non-technical users. But I don't think that the answer is to come up with new terms. It's to drastically simplify the offering (Is this what's implied in "recipes"?). Completely hide the implementation for those users.

I've been experimenting with a Torified Debian Qubes , with set VMs , and a single "standard" menu. No reference to VMs, no "domains" in the menu, no manager. Restricted applications running in the "email" and bank domain - all files are passed off to DispVMs for opening. Banking browser restricted to bank domains - this is the only thing that isn't easy to automate.
I don't have a mother to try it on, but I have given it to assorted folk, most completely non technical. The only complaints have been about browsing speed - that's Tor for you. Oh, and boot time. And that funny copy/paste thing. And slow boot times for VMs - not, of course, put in those terms. ( I mitigate that by prestarting standard VMs on login. ) And maybe some other minor stuff.
The point is that no explanation is required as long as it just works. And these are people who wouldn't find talk about VMs, recipes, qube(singular or plural) helpful. But they do want to be a little safer online.

Maybe that isn't the target?

The thing is that security is really difficult. You can improve security by educating people or by giving them tools to use, minimise the chances of misuse by enforcing use and taking away user choice. Once you let folk loose on the detail of the implementation then you had better hope they understand what they are doing and what the risks are: they wont unless they have some grasp of the technical background.
It's a moot point whether a terminology change will improve matters. I think not.

[mfc]

from Brennan's beautiful mock-ups and axon's points, it sounds like concept of a qube could be extended from just a replacement for the term AppVM to also incorporate some understanding of its netVM (ie how it connects to the internet, if it does).

So to tweak the mock-up I would say that a qube does not connect to a "Networking Qube", but rather one of the aspects of the qube itself is whether and how it networks.

That could be one of the "sides" of the qube (maybe the top?). Black if it is non-networked, purple if it is Torified, some-color for VPN, orange/yellow/red for regular clearnet.

@unman Your experiment sounds similar to discussions we have had about a "Beginner mode" for Qubes where there is not any domain management, just one AppVM and using the DispVM functionality for opening files/attachments. It would still be a step-up in security from plain Linux (or Windows...). Then there'd be "install some recipes" (Normal mode) and "I'll do it all myself" (Advanced mode).

I don't think this discussion is coming out of disagreement of target audience, just of what we think would be most helpful for new users. We all want non-technical, non-Linux users to be able to understand what Qubes does and integrate it into their existing workflows with minimum confusion. And terminology can help with that process.

[mfc]

from Brennan's beautiful mock-ups and axon's points, it sounds like concept of a qube could be extended from just a replacement for the term AppVM to also incorporate some understanding of its netVM (ie how it connects to the internet, if it does).

So to tweak the mock-up I would say that a qube does not connect to a "Networking Qube", but rather one of the aspects of the qube itself is whether and how it networks.

That could be one of the "sides" of the qube (maybe the top?). Black if it is non-networked, purple if it is Torified, some-color for VPN, orange/yellow/red for regular clearnet.

@unman Your experiment sounds similar to discussions we have had about a "Beginner mode" for Qubes where there is not any domain management, just one AppVM and using the DispVM functionality for opening files/attachments. It would still be a step-up in security from plain Linux (or Windows...). Then there'd be "install some recipes" (Normal mode) and "I'll do it all myself" (Advanced mode).

I don't think this discussion is coming out of disagreement of target audience, just of what we think would be most helpful for new users. We all want non-technical, non-Linux users to be able to understand what Qubes does and integrate it into their existing workflows with minimum confusion. And terminology can help with that process.

[rootkovska]

1. I really like the Brennan's mock-ups (except, I think we should avoid Americanisms, such as "super simple" and keep it more emotionally neutral, say just "simple").
2. I feel persuaded we should replace the term "VM" with a more catchy term, and I like the reasoning for using the term "qubes" for that.
3. I think we should use this "qubes" term for all the VMs, including the service VMs, not just AppVMs. This is to minimize the amount of different classes of abstract terms we're introducing. Also because the services VMs can also be interacted with the same way the user interacts with his or her AppVMs (e.g. I can start Terminal in my TorVM).
4. I do not like the idea of squashing of the inter-VM (sorry, inter-qubes) connectivity picture on the properties of a single, 3D-visualized, qube. Not only might that be technically difficult (hard to show 3D pictures on 2D screen or paper, also mind the color-blind users if we wanted to use colors), it really is not correct (how would you represent a situation when 2 or more VMs use the same networking VM?) and also misses one of the important points of Qubes OS -- being able to separate networking, Tor, USB, etc (so everything we represent by a "qube") from the user AppVMs (so from the user "qubes").
5. So, I think we should perhaps advertise the term "qubes" as a container for running "things" -- be that user apps, be that (admittedly abstract to many users) networking.
6. Also thanks @unman for the detailed write-up, I agree with most of what you wrote there. As Michael mentioned, we definitely want to use the "recipe" infrastructure to implement "super easy", out of the box configurations.

[rootkovska]

1. I really like the Brennan's mock-ups (except, I think we should avoid Americanisms, such as "super simple" and keep it more emotionally neutral, say just "simple").
2. I feel persuaded we should replace the term "VM" with a more catchy term, and I like the reasoning for using the term "qubes" for that.
3. I think we should use this "qubes" term for all the VMs, including the service VMs, not just AppVMs. This is to minimize the amount of different classes of abstract terms we're introducing. Also because the services VMs can also be interacted with the same way the user interacts with his or her AppVMs (e.g. I can start Terminal in my TorVM).
4. I do not like the idea of squashing of the inter-VM (sorry, inter-qubes) connectivity picture on the properties of a single, 3D-visualized, qube. Not only might that be technically difficult (hard to show 3D pictures on 2D screen or paper, also mind the color-blind users if we wanted to use colors), it really is not correct (how would you represent a situation when 2 or more VMs use the same networking VM?) and also misses one of the important points of Qubes OS -- being able to separate networking, Tor, USB, etc (so everything we represent by a "qube") from the user AppVMs (so from the user "qubes").
5. So, I think we should perhaps advertise the term "qubes" as a container for running "things" -- be that user apps, be that (admittedly abstract to many users) networking.
6. Also thanks @unman for the detailed write-up, I agree with most of what you wrote there. As Michael mentioned, we definitely want to use the "recipe" infrastructure to implement "super easy", out of the box configurations.

[andrewdavidwong]

Minor issue: "Qube" is a geometric/structural metaphor, while "recipe" is a cooking metaphor. We should avoid mixing metaphors. A "recipe" is a way to "cook up" a qube. But that's weird, because qubes aren't really "consumed". It's also the opposite of what you're going for with pre-configured qubes. A recipe is a set of instructions you follow when you cook something yourself. Pre-configured qubes are the opposite of that, because they're already configured ("cooked") for you.

[andrewdavidwong]

Minor issue: "Qube" is a geometric/structural metaphor, while "recipe" is a cooking metaphor. We should avoid mixing metaphors. A "recipe" is a way to "cook up" a qube. But that's weird, because qubes aren't really "consumed". It's also the opposite of what you're going for with pre-configured qubes. A recipe is a set of instructions you follow when you cook something yourself. Pre-configured qubes are the opposite of that, because they're already configured ("cooked") for you.

[andrewdavidwong]

@rootkovska

3 I think we should use this "qubes" term for all the VMs, including the service VMs, not just AppVMs. This is to minimize the amount of different classes of abstract terms we're introducing. Also because the services VMs can also be interacted with the same way the user interacts with his or her AppVMs (e.g. I can start Terminal in my TorVM).
[...]
5 So, I think we should perhaps advertise the term "qubes" as a container for running "things" -- be that user apps, be that (admittedly abstract to many users) networking.

Again, what about TemplateVMs?

In 3, you say you want to call all VMs "qubes," so TemplateVMs would be called qubes. Then in 5, you say that qubes should be advertised as containers for running "things." But users are not supposed to be running "things" in TemplateVMs (except, of course, to install and update software)!

[andrewdavidwong]

@rootkovska

3 I think we should use this "qubes" term for all the VMs, including the service VMs, not just AppVMs. This is to minimize the amount of different classes of abstract terms we're introducing. Also because the services VMs can also be interacted with the same way the user interacts with his or her AppVMs (e.g. I can start Terminal in my TorVM).
[...]
5 So, I think we should perhaps advertise the term "qubes" as a container for running "things" -- be that user apps, be that (admittedly abstract to many users) networking.

Again, what about TemplateVMs?

In 3, you say you want to call all VMs "qubes," so TemplateVMs would be called qubes. Then in 5, you say that qubes should be advertised as containers for running "things." But users are not supposed to be running "things" in TemplateVMs (except, of course, to install and update software)!

[rootkovska]

On Tue, Nov 17, 2015 at 09:56:10PM -0800, Axon wrote:

In 3, you say you want to call all VMs "qubes," so TemplateVMs would be
called qubes. Then in 5, you say that qubes should be advertised as
containers for running "things." But users are not supposed to be running
"things" in TemplateVMs (except, of course, to install and update software)!

That one would be the "Template for qube(s)", right? :)

[rootkovska]

On Tue, Nov 17, 2015 at 09:56:10PM -0800, Axon wrote:

In 3, you say you want to call all VMs "qubes," so TemplateVMs would be
called qubes. Then in 5, you say that qubes should be advertised as
containers for running "things." But users are not supposed to be running
"things" in TemplateVMs (except, of course, to install and update software)!

That one would be the "Template for qube(s)", right? :)

[andrewdavidwong]

That one would be the "Template for qube(s)", right? :)

So, a TemplateVM is a "Template for qube(s)"? Is it itself also a qube? If so, then since a qube should be advertised as a container for running "things" (by 5), it follows that a Template qube should also be advertised as a container for running "things" (false). If not, then since "qube" refers to all VMs (by 3), it follows that a TemplateVM is not a VM (false).

[andrewdavidwong]

That one would be the "Template for qube(s)", right? :)

So, a TemplateVM is a "Template for qube(s)"? Is it itself also a qube? If so, then since a qube should be advertised as a container for running "things" (by 5), it follows that a Template qube should also be advertised as a container for running "things" (false). If not, then since "qube" refers to all VMs (by 3), it follows that a TemplateVM is not a VM (false).

[kalkin]

It might seem very strange to a user and 3-rd party developer, if in some places we call the domains - domains, in other qubes and if we want the user to pass the domain name, we ask for the VMNAME. Also some times cli tool help talks about a domain and sometimes about a vm.

The current state according to @woju is:

This really waits for the aforementioned ticket to get fixed, however I used them in such a way:

1. for variables: vm (if referencing qubes.vm.BaseVM object, not name)
2. for documentation: domain
3. for metavar in argparse: VMNAME (since it had to be name, a str)
   (however programmer got args.vm atribute, cf. 1.)

Recently I started to change 2. into "qube" wrt #1015, however that only brings inconsistency.

And this list never made it into documentation, since there was already talk about changing the name of VM into "qube", so I didn't want to act with "done facts" against the team.

I need some kind of decision which kind of vocabulary should I use in QubesOS cli tools, manpages and the python API.

[kalkin]

It might seem very strange to a user and 3-rd party developer, if in some places we call the domains - domains, in other qubes and if we want the user to pass the domain name, we ask for the VMNAME. Also some times cli tool help talks about a domain and sometimes about a vm.

The current state according to @woju is:

This really waits for the aforementioned ticket to get fixed, however I used them in such a way:

1. for variables: vm (if referencing qubes.vm.BaseVM object, not name)
2. for documentation: domain
3. for metavar in argparse: VMNAME (since it had to be name, a str)
   (however programmer got args.vm atribute, cf. 1.)

Recently I started to change 2. into "qube" wrt #1015, however that only brings inconsistency.

And this list never made it into documentation, since there was already talk about changing the name of VM into "qube", so I didn't want to act with "done facts" against the team.

I need some kind of decision which kind of vocabulary should I use in QubesOS cli tools, manpages and the python API.

[andrewdavidwong]

Yeah, this portion of the terminology is in a messy transitional state right now. As far as documentation is concerned, we're slowly (very slowly) moving toward the term "qube" for all documentation that is intended to be consumed by non-technical end users. (For technical end users, more precise terms like "AppVM" and "TemplateBasedVM" are fine.) I've attempted to delineate this more clearly here: https://www.qubes-os.org/doc/glossary/

[andrewdavidwong]

Yeah, this portion of the terminology is in a messy transitional state right now. As far as documentation is concerned, we're slowly (very slowly) moving toward the term "qube" for all documentation that is intended to be consumed by non-technical end users. (For technical end users, more precise terms like "AppVM" and "TemplateBasedVM" are fine.) I've attempted to delineate this more clearly here: https://www.qubes-os.org/doc/glossary/

[kalkin]

@andrewdavidwong It's more about qubes vs domains vs vm and not about "AppVM" and "TemplateBasedVM"

This is a part from the qvm-block ls --help:

positional arguments:
  VMNAME                list volumes from specified domain(s)

optional arguments:
  --all                 perform the action on all domains
  --exclude EXCLUDE     exclude the domain from --all

Should it look like this? :

positional arguments:
  QUBE_NAME                list volumes from specified qube(s)

optional arguments:
  --all                 perform the action on all qubes
  --exclude EXCLUDE     exclude the qubes from --all

[kalkin]

@andrewdavidwong It's more about qubes vs domains vs vm and not about "AppVM" and "TemplateBasedVM"

This is a part from the qvm-block ls --help:

positional arguments:
  VMNAME                list volumes from specified domain(s)

optional arguments:
  --all                 perform the action on all domains
  --exclude EXCLUDE     exclude the domain from --all

Should it look like this? :

positional arguments:
  QUBE_NAME                list volumes from specified qube(s)

optional arguments:
  --all                 perform the action on all qubes
  --exclude EXCLUDE     exclude the qubes from --all

[andrewdavidwong]

According to our current "official glossary," qube, domain, and VM are all equivalent and interchangeable terms, so I suppose it depends on whether you think it's a problem to have multiple terms for the same thing. In some contexts (e.g., variable names?) maybe it is, but in other contexts (e.g., mailing lists), probably not.

[andrewdavidwong]

According to our current "official glossary," qube, domain, and VM are all equivalent and interchangeable terms, so I suppose it depends on whether you think it's a problem to have multiple terms for the same thing. In some contexts (e.g., variable names?) maybe it is, but in other contexts (e.g., mailing lists), probably not.

[bnvk]

According to our current "official glossary," qube, domain, and VM are all equivalent and interchangeable

Correct. I think getting rid of domain is the right path forward here. Using VM in technical documentation (and CLI tools) is alright, such as qvm-move-to is acceptable, while the GUI being the only place using qube in the text and docs!

However, changing qvm-move-to to qubes-move-to would be nicer, if it's not going to be a major headache, as there are other tools that start with qubes-

[bnvk]

According to our current "official glossary," qube, domain, and VM are all equivalent and interchangeable

Correct. I think getting rid of domain is the right path forward here. Using VM in technical documentation (and CLI tools) is alright, such as qvm-move-to is acceptable, while the GUI being the only place using qube in the text and docs!

However, changing qvm-move-to to qubes-move-to would be nicer, if it's not going to be a major headache, as there are other tools that start with qubes-

[andrewdavidwong]

A problem: Our official @QubesOS Twitter account recently used "domain" as a synonym for "workflow":

Reminder that @QubesOS is not about app-isolation (like e.g. iOS), but mainly about workflows (domains) isolation

[andrewdavidwong]

A problem: Our official @QubesOS Twitter account recently used "domain" as a synonym for "workflow":

Reminder that @QubesOS is not about app-isolation (like e.g. iOS), but mainly about workflows (domains) isolation

[rootkovska]

That was me tweeting. The reason for the use of 'domain' in that context was that 'qube' makes no sense outside of the Qubes OS.

[rootkovska]

That was me tweeting. The reason for the use of 'domain' in that context was that 'qube' makes no sense outside of the Qubes OS.

[andrewdavidwong]

In this case, the problem is not using "domain" instead of "qube." Rather, it's using "domain" (or "qube") to mean "workflow" instead of "VM."

But perhaps this is actually an opportunity. Instead of completely eliminating "domain" from Qubes' vocabulary, we could instead re-purpose it to mean something like "workflow."

However, I must admit that the use of "domain" to mean "workflow" strikes me as somewhat idiosyncratic, even in the context of Qubes. It seems to me that you've typically used it in the phrase "security domains," which means something like, "areas of one's digital life that require different security treatment."

[andrewdavidwong]

In this case, the problem is not using "domain" instead of "qube." Rather, it's using "domain" (or "qube") to mean "workflow" instead of "VM."

But perhaps this is actually an opportunity. Instead of completely eliminating "domain" from Qubes' vocabulary, we could instead re-purpose it to mean something like "workflow."

However, I must admit that the use of "domain" to mean "workflow" strikes me as somewhat idiosyncratic, even in the context of Qubes. It seems to me that you've typically used it in the phrase "security domains," which means something like, "areas of one's digital life that require different security treatment."

[mfc]

not sure there is a conflict, you create a qube ("banking") to protect a particular (security) domain ("my banking"). A qube is the Qubes OS implementation/reflection of a real-life security domain.

So in that way I think in the glossary the AppVM, NetVM, ProxyVM should be defined as qubes (done, not done, not done), the qube should be defined as application or service VMs for particular security domains (~done but ambiguous), and the domain should not be defined as a software implementation but instead the real-life security domain a user is trying to have reflected within Qubes OS (opposite of what is currently there).

I don't think domain is equivalent to workflow, a workflow can involve multiple qubes (and security domains): for example your "work email" workflow could involve torified "email" and offline "split-gpg" qubes. this is something that could be clarified by the VM Manager by enabling the user to group qubes into workflows (using recipes, manually, etc).

[mfc]

not sure there is a conflict, you create a qube ("banking") to protect a particular (security) domain ("my banking"). A qube is the Qubes OS implementation/reflection of a real-life security domain.

So in that way I think in the glossary the AppVM, NetVM, ProxyVM should be defined as qubes (done, not done, not done), the qube should be defined as application or service VMs for particular security domains (~done but ambiguous), and the domain should not be defined as a software implementation but instead the real-life security domain a user is trying to have reflected within Qubes OS (opposite of what is currently there).

I don't think domain is equivalent to workflow, a workflow can involve multiple qubes (and security domains): for example your "work email" workflow could involve torified "email" and offline "split-gpg" qubes. this is something that could be clarified by the VM Manager by enabling the user to group qubes into workflows (using recipes, manually, etc).

[andrewdavidwong]

not sure there is a conflict

Between what?

So in that way I think in the glossary the AppVM, NetVM, ProxyVM should be defined as qubes (done, not done, not done), the qube should be defined as application or service VMs for particular security domains (~done but ambiguous)

Can you try rephrasing this? I have no idea what you mean.

and the domain should not be defined as a software implementation but instead the real-life security domain a user is trying to have reflected within Qubes OS (opposite of what is currently there).

Sure, that's fine.

I don't think domain is equivalent to workflow, a workflow can involve multiple qubes (and security domains): for example your "work email" workflow could involve torified "email" and offline "split-gpg" qubes.

Agreed.

this is something that could be clarified by the VM Manager by enabling the user to group qubes into workflows (using recipes, manually, etc).

Not so sure about that. Sounds like a complicated UI/UX decision.

[andrewdavidwong]

not sure there is a conflict

Between what?

So in that way I think in the glossary the AppVM, NetVM, ProxyVM should be defined as qubes (done, not done, not done), the qube should be defined as application or service VMs for particular security domains (~done but ambiguous)

Can you try rephrasing this? I have no idea what you mean.

and the domain should not be defined as a software implementation but instead the real-life security domain a user is trying to have reflected within Qubes OS (opposite of what is currently there).

Sure, that's fine.

I don't think domain is equivalent to workflow, a workflow can involve multiple qubes (and security domains): for example your "work email" workflow could involve torified "email" and offline "split-gpg" qubes.

Agreed.

this is something that could be clarified by the VM Manager by enabling the user to group qubes into workflows (using recipes, manually, etc).

Not so sure about that. Sounds like a complicated UI/UX decision.

[andrewdavidwong]

One problem with not using "domain" as a synonym for "VM" is that this diverges from Xen's usage (e.g., "dom0" is short for domain zero), but I think it's fine for us to diverge from Xen, since it seems that our goal is to mostly hide Xen from the user.

[andrewdavidwong]

One problem with not using "domain" as a synonym for "VM" is that this diverges from Xen's usage (e.g., "dom0" is short for domain zero), but I think it's fine for us to diverge from Xen, since it seems that our goal is to mostly hide Xen from the user.

[andrewdavidwong]

As a general point, one advantage of using the term of abstraction "qube" instead of "VM" is that, if Qubes OS were ever to implement a form of compartmentalization that does not use virtual machines (but rather some other kind of underlying container), the term "qube" could usefully encompass all types of compartments used in Qubes OS.

[andrewdavidwong]

As a general point, one advantage of using the term of abstraction "qube" instead of "VM" is that, if Qubes OS were ever to implement a form of compartmentalization that does not use virtual machines (but rather some other kind of underlying container), the term "qube" could usefully encompass all types of compartments used in Qubes OS.

[tasket]

I have to agree with the initial reactions here, despite liking the idea. Whenever we referred to 'qube' in the plural (qubes) there would be high potential for confusion with Qubes OS itself.

Looking afield, we see that Docker has 'containers'. No confusion there.

OTOH, should we use a term to hide the VM aspect? Probably, since Qubes is supposed to be more technology agnostic than that. Qubes would also benefit in the ecosystem sense if its architecture produced specific object types with common names (like 'container'); Then you have a userbase that can grow by making the objects available (and, therefore, tempting to try).

For example, a VPN provider could configure a proxy vm (proxy container?) entirely in the private.img /rw/config so a user would only have to download the vm and (um, somehow) install it, perhaps using a special mode of qvm-backup-restore.

I see some options here:

1. Go with 'qube' and suffer the conversational problems
2. Adopt Docker's term, as 'Qubes container'
3. Return to Xen 'domain', accept it on other platforms for historical reasons
4. Use another word like: box, vessel, canister, drum, case, chamber
5. Use a word that relates to the concept: encapsulation=capsule, isolation=solon? isol? cordon?
6. Play on geometry: sphere, ring
7. Coin a permutation such as qbox, qdrum, qcase, qring
8. Abbreviation, like 'qu' from 'Qubes domU' which we could playfully pronounce as simply /kyoo/ or maybe /kyoo-yoo/.

Choosing a permutation or rare word brings a semantic bonus: Greater clarity in Internet searches and greater ownership of the concept. You also don't have to qualify it as "Qubes domain" nearly as often if you just say 'qbox' or 'qu'.

My favorites so far: Qu, cordon, qbox, isol, qcase
...but if you're going to be conservative (which 'qube' is) then I think container or domain is better.

[tasket]

I have to agree with the initial reactions here, despite liking the idea. Whenever we referred to 'qube' in the plural (qubes) there would be high potential for confusion with Qubes OS itself.

Looking afield, we see that Docker has 'containers'. No confusion there.

OTOH, should we use a term to hide the VM aspect? Probably, since Qubes is supposed to be more technology agnostic than that. Qubes would also benefit in the ecosystem sense if its architecture produced specific object types with common names (like 'container'); Then you have a userbase that can grow by making the objects available (and, therefore, tempting to try).

For example, a VPN provider could configure a proxy vm (proxy container?) entirely in the private.img /rw/config so a user would only have to download the vm and (um, somehow) install it, perhaps using a special mode of qvm-backup-restore.

I see some options here:

1. Go with 'qube' and suffer the conversational problems
2. Adopt Docker's term, as 'Qubes container'
3. Return to Xen 'domain', accept it on other platforms for historical reasons
4. Use another word like: box, vessel, canister, drum, case, chamber
5. Use a word that relates to the concept: encapsulation=capsule, isolation=solon? isol? cordon?
6. Play on geometry: sphere, ring
7. Coin a permutation such as qbox, qdrum, qcase, qring
8. Abbreviation, like 'qu' from 'Qubes domU' which we could playfully pronounce as simply /kyoo/ or maybe /kyoo-yoo/.

Choosing a permutation or rare word brings a semantic bonus: Greater clarity in Internet searches and greater ownership of the concept. You also don't have to qualify it as "Qubes domain" nearly as often if you just say 'qbox' or 'qu'.

My favorites so far: Qu, cordon, qbox, isol, qcase
...but if you're going to be conservative (which 'qube' is) then I think container or domain is better.

[andrewdavidwong]

For example, a VPN provider could configure a proxy vm (proxy container?) entirely in the private.img /rw/config so a user would only have to download the vm and (um, somehow) install it, perhaps using a special mode of qvm-backup-restore.

We actually have an issue for that functionality: #1747

[andrewdavidwong]

For example, a VPN provider could configure a proxy vm (proxy container?) entirely in the private.img /rw/config so a user would only have to download the vm and (um, somehow) install it, perhaps using a special mode of qvm-backup-restore.

We actually have an issue for that functionality: #1747

[tasket]

Some more terms:

qapsule
fort
brig, qbrig
briq

I really like briq...

[tasket]

Some more terms:

qapsule
fort
brig, qbrig
briq

I really like briq...

[TBK]

I would call a TemplateVM a Slab, Foundation or a Base which upon a Qube is placed to create ..... (need anology of container).

Base is a geometric term - https://en.wikipedia.org/wiki/Base_(geometry)

[TBK]

I would call a TemplateVM a Slab, Foundation or a Base which upon a Qube is placed to create ..... (need anology of container).

Base is a geometric term - https://en.wikipedia.org/wiki/Base_(geometry)