Use our own terminology more consistently throughout the system

[andrewdavidwong]

Qubes OS version:

R4.0.1

---

"Qubes Domains: View and manage running domains."

From our glossary's definition of domain:

An area or set of activities in one’s digital life that has certain security requirements and therefore involves the use of certain qubes. For example, suppose your “email” domain encompasses the activity of sending PGP-encrypted email. This domain may include your email qube and your Split GPG qube. Note that domains and qubes are not the same thing. In this example, your “email” domain includes the use of two qubes. Furthermore, a qube can fall under multiple domains simultaneously. For example, your Split GPG qube may also be part of your “software development” domain if you PGP-sign your Git commits.

So, this is a misuse of the term. Similarly, in the Application Launcher, we have Domain: <vm_name>, which is the same kind of misuse.

"Create Qubes VM"

Either we should decide to use the term "VM" freely, or it should not be in the name of this nontechnical-user-facing tool (see #1015).

After clicking on Create Qubes VM, the window title is called Create new qube. This implies that "qube" is a synonym for "VM" (see QubesOS/qubes-doc#764; CC: @unman).

When selecting a type, there are three options:

• AppVM
• Standalone qube based on a template
• Standalone qube not based on a template

"Standalone qube based on a template" is a contradiction in terms, because a StandaloneVM is by definition a VM that is not based on a template. Conversely, "Standalone qube not based on a template" is redundant for the same reason. I think you probably meant "copied from" instead of "based on" here.

[marmarta]

@marmarek, I think you should read this too.
To be honest I am apparently a little confused by the terminology here. I was under the impression we were phasing out 'VM' in almost all places and replacing it by 'qube', while 'domain' would be an AppVM. I'm fine with any definition, as long as we all have just one set of those :)

[andrewdavidwong]

I was under the impression we were phasing out 'VM' in almost all places and replacing it by 'qube'

I am under the same impression, which is why I opened this issue in order to point out that we have a menu entry called Create Qubes VM, which opens a window with the title Create new qube.

• Shouldn't the menu entry be called Create new qube also?
• Shouldn't the menu entry and the window title be the same, regardless of which name we choose?

(However, it's unclear to me whether we're actually still committed to using the term "qube" in this way, which is why I asked about that in #1015 (comment).)

while 'domain' would be an AppVM

I'm not aware of such a change in meaning. (By contrast, I am aware of a change in the meaning of "AppVM," as discussed in QubesOS/qubes-doc#748.)

I'm fine with any definition, as long as we all have just one set of those :)

I might be a bit more picky about which definitions we choose, but I agree that there should be just one set. :)

[andrewdavidwong]

• Discussion about whether we should switch from "[App]VM" to "qube" and the best way to do so should be on Consider changing "AppVM" to "qube" for better UX #1015, not here.
• There is a big difference between "AppVM" and "VM." They do not mean the same thing. Therefore, it matters whether "qube" means "AppVM" or whether it means "VM." See Qubes 4.0 Getting Started qubes-doc#764 (comment). Maybe we can get away with "qube" being ambiguous between these, but that should be a conscious decision carefully made. I am not optimistic that efforts to constrain "qube" to being a synonym of just "AppVM" (as opposed to "VM") will succeed. Even in this discussion among Qubes experts, the distinction was not recognized.

[h01ger]

On Fri, Jan 18, 2019 at 04:51:33PM -0800, Andrew David Wong wrote: - Discussion about whether we should switch from "[App]VM" to "qube" and the best way to do so should be on #1015, not here. - There is a big difference between "AppVM" and "VM." They do not mean the same thing. Therefore, it matters whether "qube" means "AppVM" or whether it means "VM." See QubesOS/qubes-doc#764 (comment). Maybe we can get away with "qube" being a ambiguous between these, but that should be a conscious decision carefully made. I am not optimistic that efforts to constrain "qube" to being a synonym of just "AppVM" (as opposed to "VM") will succeed. Even in this discussion among Qubes experts, the distinction was not recognized.

maybe the (granted, long-term) solution then is to call it AppQube (etc)?!

…

-- tschüß, Holger

------------------------------------------------------------------------------- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[marmarta]

@andrewdavidwong , I've made the Create New VM dialog use the following:

-Qube based on a template (AppVM)
-Standalone qube
-Standalone qube copied from a template

What do you think about it?

[andrewdavidwong]

@andrewdavidwong , I've made the Create New VM dialog use the following:

-Qube based on a template (AppVM)

I still think we should preserve the distinction between VMs-for-running-applications (R3.2 AppVMs) and TemplateBasedVMs, but if we're not doing that, then this is fine.

-Standalone qube
-Standalone qube copied from a template

What do you think about it?

What is the difference between Standalone qube and Standalone qube copied from a template? In other words, if Standalone qube is not copied from a template, where does it come from?

[marmarek]

In other words, if Standalone qube is not copied from a template, where does it come from?

It's empty, without any system installed. You can install a system there by starting it from some installation cdrom (image).

[andrewdavidwong]

In other words, if Standalone qube is not copied from a template, where does it come from?

It's empty, without any system installed. You can install a system there by starting it from some installation cdrom (image).

Maybe this option should say something like:

Empty standalone qube (install your own OS)

[qubesos-bot]

Automated announcement from builder-github

The package qubes-desktop-linux-manager_4.1.10-1 has been pushed to the r4.1 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing buster-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component desktop-linux-manager (including package qubes-desktop-linux-manager-4.1.10-1.fc32) has been pushed to the r4.1 testing repository for the Fedora template.
To test this update, please install it with the following command:

sudo dnf update --enablerepo=qubes-vm-r4.1-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package desktop-linux-manager has been pushed to the r4.1 stable repository for the CentOS centos-stream8 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-desktop-linux-manager_4.1.10-1+deb10u1 has been pushed to the r4.1 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component desktop-linux-manager (including package qubes-desktop-linux-manager-4.1.10-1.fc32) has been pushed to the r4.1 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo dnf update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component desktop-linux-manager (including package qubes-desktop-linux-manager-4.1.10-1.fc32) has been pushed to the r4.1 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[andrewdavidwong]

Some user feedback:

https://twitter.com/Piniora/status/1462043541237022722

I see inconsistency in naming scheme.
There are:

• Create Qubes VM
• Qubes Global Settings
• Qubes Update
• Qubes Template Manager
• Backup/Restore Qubes

and suddenly in:

• Qube Manager
  which shows all Qubes, their state, ip, storage.

[unman]

The first should be "Create qube" The rest seem consistent with our naming scheme, unless we change "Backup/Restore Qubes" to "Backup/Restore qubes" for clarity. Qubes in the first section refers to the OS - these are functions of the OS. "Qube manager" because it's a manager for qubes, not for the OS. Isnt that clear? What could be improvement?

[andrewdavidwong]

The first should be "Create qube" The rest seem consistent with our naming scheme, unless we change "Backup/Restore Qubes" to "Backup/Restore qubes" for clarity. Qubes in the first section refers to the OS - these are functions of the OS. "Qube manager" because it's a manager for qubes, not for the OS. Isnt that clear? What could be improvement?

It's clear to me but apparently not to everyone. See my replies.

This is just one person's feedback, though, not a big data set.