Edit: Split from the thread linked below. Suggestions for a good title are welcome
Having “Qubes” refer to the OS and “qube” refer to a VM can also lead to confusion among new users. Even older users suffer (especially those who speak other languages) since they can sometimes confuse the two when communicating.
The name “Qubes” probably isn’t going to change, but having a different name for VMs would be nice. The semantics of Qubes OS being a collection of qubes isn’t as important.
Giggling at the thought of a new proposal with lots of Very UX Research lingo, suggesting to introduce the metaphor of so-called virtual machines, or “VMs” in Qubes OS
I glanced over the thread and noticed that you --and @marmarek, and @unman, and @adrelanos (Whonix), and even Joanna– weren’t fans of the term ‘qube’.
How on earth did it end up in production!?
Edit: I read a bit more of that long thread and it turns out some switched sides over the years.
Since this was literally a decade ago, now would be a reasonable time to revisit this topic and fight the good fight again–it’s never too late to backtrack on bad design decisions.
To be clear, I have no love for “VM”, but it’s the established term for what these things literally are, and everyone’s already using the terms ‘sys-VM’, ‘app-VMs’, etc.
The camp pushing for ‘qube’ has this silly notion that the term will help with widespread adoption among laypeople but it actually does the opposite–because, on top of having to learn this entirely alien system, users also have to pay attention to these tiny cues when navigating the UI, reading the documentation, and communicating. If I can’t easily tell at a glance the difference between “Qubes” and “Qube” (often capitalized in titles, at the start of sentences, etc.), it’s a failure of design.
Any person savvy enough to use Qubes is savvy enough to know that Qubes is a collection of VMs; we shouldn’t need to hold their hands and dance around the term. We should be calling a spade, “a spade”–not “a quonk”.
I just had a flash–if we must avoid ‘VM’, why not call them ‘Q’?
It’s short to say, read, and type; catchy; unambiguous in most contexts; captures Qubes OS’s distinct initial; round; friendly; somewhat classy (reminds me of Q, the gadget man from James Bond).
One downside is it can jump out too much, visually.
Example:
“To make a Q for browsing the web, create a Debian template-Q and install firefox-esr, then click the ‘New Q’ button at the top left of the Q Manager to create a new app-Q.”
For me, this topic really has no place and is strictly useless. Should we say VM, qubes or qube or sys-VM or AppVm or sysVm or AppVm or etc… or not, frankly, is it so important?
I dare to hope that the community is able to understand what we are talking about with or without “s” or “-” with or without capitalization. We speak completely different languages and we all understand each other quite a bit in English
Now I want to read advice like, “you need intrusion detection and tripwires to make sure nobody’s in your Q”.
This is a legitimate reason for a name change.
@Tezeria I don’t think this particular topic is very important, but I think language (or more specifically, the words we use to communicate and reference things) is important, but lets agree to disagree
The virtual machines inside Qubes - or any other virtualisation platform - will be always referred as VMs. period. Because they are in fact virtual machines.
I would never ever going to be call then by any different name, but VMs.
And I’m using Qubes since the very first beta releases
(and that was 10+ years ago)
No matter why anybody thinks it’s need a ‘new name’… the time will tell, how the real users will call them.
The problem with these ‘renaming’ projects are that the initiator/supporters of such good ideas are usually not a real user… But correct me if I’m wrong
I have always seen qube as a concept, and not a technical definition.
If you want examples of users not understanding Qubes OS virtualization, you just have to read the forum, lots of (new) users seems to think dom0 is bare-metal and running Xen.
To me, it makes sense to have an abstraction like qube.
Qubes in Qubes OS: Should we be calling VMs ‘qubes’
I have not read this entire thread. But considering Qubes Air introduction, in very near future, a qube could be a real physical remote hardware and not a virtual machine at all (watch the related video on Qubes Air in last year summit). So the answer is we would better use qube to be able to address both.
In the future another provider might be in use for compartmentalization, e.g. Docker instead of Xen. The terminology would stay the same, as a user wouldn’t care, how the compartments are realized technically.
Disagree. Some users, me included, think in metaphors, rather than purely technical aspects. Some are completely non-technical. Why force them to learn the technical aspects, rather than give them some easy-to-grasp metaphors?
My two cents: I like calling the Virtual Machines in QubesOS “qubes”. It symbolizes the separation or “compartmentalization” that QubesOS is best known for. Everything runs in its little box… or cube… called “qube”.
So you think they just accept what they get? and happily trust the vendor because they said so? - like an average iPhone user?
I must disagree.
It is a nice idea that Qubes OS is for everyone… or even just for an ‘average user’. But that’s just a very unrealistic ‘marketing’ slogan.
If a user cares about security, then it is already above the average.
If a user willing to try something completely new (compared to the mainstream Windows, Mac line) then it is way above the average.
If a user choosing an OS/project/solution because it is open source - that’s surely not an average user.
And I would say if one choose to use Qubes OS for a reason, then it also must learn some relevant terms like: virtual machine, Xen, dom0, domU, virtualization, PCI PassTrough, basic networking. Otherwise they will surely fail.
But I would go more far about this:
if a Qubes user don’t know what the difference between Xen, KVM, Hyper-v, VMware, or docker… then they still not understand how Qubes is standing out from anything else out there.
I would be surely pissed off if Qubes would like to ‘hide’ such important information - or even if just try to say that the user should not care about those details!
Even the virtualisation Mode (PHV, HVM, PV) is very important, hence the Qube Manager still shows it.
And they made their opinion very clear in the FAQ:
I think ‘qube’ as an umbrella term for units of compartmentalization (e.g. VMs, Qubes Air elements, etc.) is acceptable. However it will still have the same issues we started with–it’s easy to confuse ‘Qube’ with ‘Qubes’.
My main argument is we should move from ‘qube’ to something else, not necessarily ‘VM’, even though that was my most preferred candidate (if you look at the first version of my second post, you’ll see I said “I just want anything other than ‘qube’”).
You should also know that most people on the forum refer to a ‘qube’ as a ‘VM’. Here’s an unfiltered list of relevant thread titles from the last ten days, sorted by recently updated, at 00:00 GMT, 17 July:
I disagree. There’s nothing more logical and easy to remember than the fact the Qubes operating system (with big ‘Q’) operatesqubes (with low-case ‘q’), which are its units of compartmentalization. It’s just perfect, especially for attracting non-technical people who may not care about the underlying technology (which is fine!).
VM is the close second, and today it’s interchangeable, which is why people are using both, including myself. But as mentioned above, it won’t remain just VMs in the future.
As one of the ~25% who have recently employed the term qube, I’ll chime in. I appreciate having a more colloquial way of referring to virtual machines, especially when crafting a long community guide. It helps keep the language from presenting as too dry, technical, and repetitive. That said, I tend to think in terms of appVMs and other types of virtual machines, rather than in types of qubes.