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?

[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.

[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?

[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.

[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.

[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.")

[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.

[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 https://github.com/QubesOS/qubes-issues/issues/1015#issuecomment-155606604

[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.

[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.

[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]

@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? :)

[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.

[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

[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-

[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.

[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).

[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]

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.

[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: https://github.com/QubesOS/qubes-issues/issues/1747

[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)

[andrewdavidwong]

In https://github.com/QubesOS/qubes-doc/pull/764, it looks like we're going to introduce new users to "qubes" and "templates."

@marmarek, are we still committed to using the term "qube" in this way?

[marmarek]

Yet another case of inconsistency: https://github.com/QubesOS/qubes-manager/pull/151/files#diff-30e1c1082a7d01b7dbd25a8a0c428812R834:

Allow starting Disposable VMs from this qube

I think the general idea of using "qube" is good, but we need to use it consistently. We have multiple cases:

1. Generic name for a VM ("qube settings", "create qube")
2. Names of VM types (TemplateVM, StandaloneVM, AppVM, DisposableVM)
3. VM types removed in R4.0 (NetVM, ProxyVM) - in R4.0 those are just VMs with provides_network property set to true.
4. Functional names, like UpdateVM, ClockVM, soon GuiVM. And also default_dispvm and management_dispvm properties (but see below).

Anything else?

I think the first point is simple - just using "qube" there should be ok. The second one is more tricky though, as it apply to both presentation layer (how tools display them) and internal code. Maybe types should have "VM" suffix stripped, so it would be "Template", "Standalone", "App", etc? The "App" sounds strange, any better idea? While at it, we probably should rename "Disp(VM)" to full "Disposable(VM)". I've seen at least once this abbreviation resulted in confusion (Display VM). The third point may be just about dropping those terms, but looking at various docs, it would be convenient to have a term for "qube with privides_network property set to true". Especially as this may be any qube type. "Proxy qube" may not be a good idea, as it may be confused with actual qube type. Any better idea? Or maybe it isn't a problem?

While we're discussing terminology, another related issue we should solve is "DVM template". This term has both "VM", and obscure abbreviation "DVM" from "DispVM" (which itself is from Disposable VM). Additionally we have "default_dispvm" property, which actually points at DVM template, not Disp(osable)VM. "Disposable qube template" I think is too long, but I don't have any better idea.

As for the fourth point, maybe we should simply rename those to UpdateQube, ClockQube? This is both about presented name, and actual global properties. I'm not sure if that's the best idea...

There is also qrexec policy, which have various keywords containing "VM": @anyvm, @dispvm.

We should figure it out before Qubes 4.1 release, as some of this may require incompatible changes (like renaming VM types). We'd also need to decide how to handle it in various tools - should old names be rejected (breaking various user custom scripts), or automatically translate to new names (potentially resulting in some confusion like creating "AppVM" could result in creating "App" or whatever new name will be).

@andrewdavidwong we need your help here. @mfc maybe you have some ideas here? @marmarta?

[HW42]

Anything else?

How will we refer to PV/PVH/HVM? We probably should have a consistent way to say qube/VM with virt_mode=$x. Probably simply "PV qube" should work, but might be a bit confusing with the old 'HVM'.

Should we avoid "dom0" and "domU" if possible (For example @andrewdavidwong made heavy use of it in QSB #45, probably because of the not yet decided exact meaning of "qube").

---

The third point may be just about dropping those terms, but looking at various docs, it would be convenient to have a term for "qube with privides_network property set to true". Especially as this may be any qube type. "Proxy qube" may not be a good idea, as it may be confused with actual qube type. Any better idea? Or maybe it isn't a problem?

What about just "net qube". This would match the use of netvm (the property not the class).

---

Maybe types should have "VM" suffix stripped, so it would be "Template", "Standalone", "App", etc? The "App" sounds strange, any better idea?

What about "TemplateBased"?

We should figure it out before Qubes 4.1 release, as some of this may require incompatible changes (like renaming VM types). We'd also need to decide how to handle it in various tools - should old names be rejected (breaking various user custom scripts), or automatically translate to new names (potentially resulting in some confusion like creating "AppVM" could result in creating "App" or whatever new name will be).

Breaking a lot of scripts "just" for renaming things doesn't sound nice, especially after the switch to 4.0 already had a lot of churn. OTOH having code to handle the old names in a lot of places sounds worse in the long term, so I would go with changing the names consistently if we want to use "qube" consistently.

---

When all those naming decisions are done we should not only update the glossary with the updated meaning but also with the preferred form/usage (for example "Use qube instead of VM in Qubes documentation and code.", or whatever gets decided).

[andrewdavidwong]

@marmarek:

Yet another case of inconsistency: https://github.com/QubesOS/qubes-manager/pull/151/files#diff-30e1c1082a7d01b7dbd25a8a0c428812R834:

Allow starting Disposable VMs from this qube

I think the general idea of using "qube" is good, but we need to use it consistently. We have multiple cases:

1. Generic name for a VM ("qube settings", "create qube")
2. Names of VM types (TemplateVM, StandaloneVM, AppVM, DisposableVM)
3. VM types removed in R4.0 (NetVM, ProxyVM) - in R4.0 those are just VMs with provides_network property set to true.
4. Functional names, like UpdateVM, ClockVM, soon GuiVM. And also default_dispvm and management_dispvm properties (but see below).

Anything else?

I think the first point is simple - just using "qube" there should be ok. The second one is more tricky though, as it apply to both presentation layer (how tools display them) and internal code. Maybe types should have "VM" suffix stripped, so it would be "Template", "Standalone", "App", etc? The "App" sounds strange, any better idea? While at it, we probably should rename "Disp(VM)" to full "Disposable(VM)". I've seen at least once this abbreviation resulted in confusion (Display VM). The third point may be just about dropping those terms, but looking at various docs, it would be convenient to have a term for "qube with privides_network property set to true". Especially as this may be any qube type. "Proxy qube" may not be a good idea, as it may be confused with actual qube type. Any better idea? Or maybe it isn't a problem?

While we're discussing terminology, another related issue we should solve is "DVM template". This term has both "VM", and obscure abbreviation "DVM" from "DispVM" (which itself is from Disposable VM). Additionally we have "default_dispvm" property, which actually points at DVM template, not Disp(osable)VM. "Disposable qube template" I think is too long, but I don't have any better idea.

As for the fourth point, maybe we should simply rename those to UpdateQube, ClockQube? This is both about presented name, and actual global properties. I'm not sure if that's the best idea...

There is also qrexec policy, which have various keywords containing "VM": @anyvm, @dispvm.

We should figure it out before Qubes 4.1 release, as some of this may require incompatible changes (like renaming VM types). We'd also need to decide how to handle it in various tools - should old names be rejected (breaking various user custom scripts), or automatically translate to new names (potentially resulting in some confusion like creating "AppVM" could result in creating "App" or whatever new name will be).

@andrewdavidwong we need your help here. @mfc maybe you have some ideas here? @marmarta?

See my comments on https://github.com/QubesOS/qubes-doc/pull/764 and https://github.com/QubesOS/qubes-issues/issues/4723, which already covers a lot of this.

In general, I think it would be a mistake to change this terminology at any technical (i.e., command-line, script, or code) level. We have always said that "qube" would just be a user-friendly term for non-technical users and that more precise terms should be used in technical contexts (see the "qube" glossary entry).

I personally don't believe that trying to replace "AppVM" or "VM" with "qube" will provide any real benefit. I think it'll just cause confusion, be messy, and take up a lot of time and effort. It's not hard to learn what "VM" means, and I think that all Qubes users will have to understand what it means for the foreseeable future.

If you decide to persist with using "qube," the most straightforward way would be as a direct replacement for every instance of "VM." Any effort to restrict the definition (e.g., to "AppVM") will certainly fail, since almost everyone on the Qubes dev team is still conflating "AppVM" and "VM" when talking about using the term "qube" (even your own post does this). So, there is no hope that ordinary users will heed such a distinction.

As I mentioned above, the introduction of the term "qube" has one advantage: It adds a layer of abstraction. A "qube" is an abstract compartment independent of the underlying technology used to implement it. While the underlying implementation is currently a virtual machine, it is conceivable that Qubes OS might one day use a different kind of underlying technology for compartmentalization, in which case a "qube" may no longer be a VM. But this is a pretty minor benefit that we won't be able to reap for a long time (if ever), while the costs are immediate.

---

@HW42:

Should we avoid "dom0" and "domU" if possible (For example @andrewdavidwong made heavy use of it in QSB #45, probably because of the not yet decided exact meaning of "qube").

No, that was intentional, because "dom0" and "domU" are the accurate and precise technical terms, and it is especially important to be accurate and precise in QSBs, which are, by their nature, technical documents. However, I can imagine restricting technical language to certain sections of the document and trying to make the user-actionable parts as accessible as possible.

[HW42]

Any effort to restrict the definition (e.g., to "AppVM") will certainly fail, since almost everyone on the Qubes dev team is still conflating "AppVM" and "VM" when talking about using the term "qube" (even your own post does this). So, there is no hope that ordinary users will heed such a distinction.

I think at least part of this comes from the fact that there are two meanings of "AppVM". One is is the "A VM that is intended for running software application [through the user]" definition. The other is the AppVM class as used in 4.0 which is used for all template-based VMs (as oposed to AdminVM, DispVM, StandaloneVM and TemplateVM).

[marmarek]

I think at least part of this comes from the fact that there are two meanings of "AppVM".

Yes, this is also a problem. Similar to ProxyVM term ("net qube"). So, maybe we should have "app qube" and "TemplateBased" qube type?

[andrewdavidwong]

I think at least part of this comes from the fact that there are two meanings of "AppVM". One is is the "A VM that is intended for running software application [through the user]" definition. The other is the AppVM class as used in 4.0 which is used for all template-based VMs (as oposed to AdminVM, DispVM, StandaloneVM and TemplateVM).

Neither meaning of "AppVM" is being distinguished from "VM" in most of these discussions. I suppose it's possible that the existence of more than one meaning makes one uncertain of which distinction to make, so one decides to make no distinction at all. But I'm not interested in placing blame on anyone for their use of this term. On the contrary, I'm saying that we should learn from the way people are using the term in practice. After observing the way people have started using "qube" to mean just "VM," it's clear that we will not be able to restrict its meaning to some proper subset of VMs.

Yes, this is also a problem. Similar to ProxyVM term ("net qube"). So, maybe we should have "app qube" and "TemplateBased" qube type?

That would at least preserve the two distinct concepts denoted by "AppVM" at different times.

[brendanhoar]

One possible source of confusion, should "VM" be replaced with "qube" in docs/UI/configs, is that the plural VMs becomes "qubes". Then it may be less clear, depending upon context, if this is meant to refer to multiple VMs or to the OS as a whole.

Brendan

[andrewdavidwong]

One possible source of confusion, should "VM" be replaced with "qube" in docs/UI/configs, is that the plural VMs becomes "qubes". Then it may be less clear, depending upon context, if this is meant to refer to multiple VMs or to the OS as a whole.

This was already covered in the discussion above, and our glossary already contains this note:

The term “qube” should be lowercase unless it is the first word in a sentence. Note that starting a sentence with the plural of “qube” (i.e., “Qubes…”) can be ambiguous, since it may not be clear whether the referent is a collection of qubes or Qubes OS.

[ninavizz]

Naming should inform mental models of how the broader ecosystem of QubesOS works. As such, I personally like calling VMs "qubes," which depending on the context can get confusing. There is never an absolutely-perfect answer for any/every context, imho—especially because VMs in Qubes are used for so many different things. Common mental-models of VMs are, "Oh, I need to run another OS" or "Oh, I need a dev box," not "Oh, I need to isolate devices from internet from apps from where my library of distributions are kept."

I feel like there are bigger fish to fry for the time being. There also needs to be a friendly introduction to QubesOS, separate from the docs, that explains how the ecosystem works to newbies. Something Marta and I have discussed a bit. Docs imho need to be more for nitty-gritty details stuff, and outlining best practices; less for "here is generally how this thing works."