Not complaining, or really disputing, because I think I might be in a (very small) minority here, but…
I have to say here that even after getting some familiarity with it, I am finding that this new term causes mental confusion every time I meet it.
I have netvm (could be “net qube”) for my network interface, “audio qube” or audiovm feels like another interface, clockvm is an interface to the internet time.
Qubes feels like a whole family of cleverly designed cooperating interfaces, and “interface qube” seems quite weird and unintuitive.
I fully agree that jargon is bad, but “GUI” feels like common usage, almost vernacular, and is not far from what this particular interface is doing…
OK. I just had to say it out loud without spamming any github issues. Will shut up now.
Why?
They are separate qubes that offer services. It’s like in an office: it’s one office but every worker have it’s separate cubicle. One worker in one qube is doing something to outside world but other worker is doing something that other workers in that office need for it’s own work.
What’s confusing in that?
Yes, I tried some analogies, but I did not find one that worked for me.
I'm not disagreeing, but...
it feels to me like that company where worker 1 talks to the outside company that does marketing, W2 talks to the office cleaning company, W3 to the accountant, etc, etc, etc, but only Wx gets called the “Outside Services handler”, even though they only talk to the Cloud management company for the website.
“Outside services” is too broad, it could refer to all those . It would need a detailed explanation for any new worker.
They would know what the accountancy handler does, and the office cleaning handler. Only one would not be clear…
Like “Cloud” is not the only “Outside service” for that company, “GUI” is not the only “Interface” in my Qubes mind.
Like I didn’t exactly say - I think it must be obvious to almost everyone else.
For readers wondering about what we are talking about, here’s the Github issue:
“GUI” is definitely bad. I don’t think that users using only GUIs are aware that they use a “GUI”. Even using the command-line, GUI wasn’t an obvious acronym for the other interfaces (it was just the “regular” way to deal with computers). There is some related UX advice in the docs, using “GUI” as an example: Usability & UX — Qubes OS Documentation
About your analogy, Qubes OS provides some GUIs that are not in the “GUI domain” too…
“interface qube” was just a suggestion taken from the docs. It seems like we haven’t found any better suggestion. I don’t think it is a word we use much in user support, so it’s okay for me, but anyway, thanks for the feedback.
it feels to me like that company where worker 1 talks to the outside company that does marketing
No. worker 1 is not going into city to talk to outside company. He uses communication service provided by IT department. And he uses worker 999 artwork in it’s work even thought worker 999 have no connection to outside of office. But there is internal network for workers to communicate.
I'm really going to hit thread mute next, I promise.
It is just that all the other candidates seem worse (IMHO).
At least “GUI” has a reasonably pertinent wikipedia page, in multiple languages, for anyone in the space of not immediately having an intuitive understanding, but wanting/needing to get into the tripes of Qubes.
I started my learning from a rummage through qvm-prefs output, and I never had to give guivm a thought, after seeing how netvm chains worked. It was enough for a year, at least.
It is not precisely applicable, I think, but it is a lot better than any of the contorted explanations that I can imagine. Like my failed analogy.
Without prejudice to them, many who turn off at “GUI” will probably present bigger challenges for support and training than will be cured by a friendly but woolly(?)/ neologism.
That’s the name of a qube, whereas this is descriptive. There can be
many interface qubes, and they may also provide other services.
GuiVM, GUIVM, GUI domain - these have all been used in the past.
Just as we moved from DispVM to disposable, it’s an effort to move
away from the use of VM and domain. Not ideal, but I like it.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Just to verify my understanding… and make more clear my lonely objection:
‘disposable’ (as a noun) is the same as ‘disposable qube’
‘disposable template’ is expected to persist as the term for the obvious - template for the above.
“audio qube” is both
a role, fulfilled - or not - by the qube indicated -or not- in a pref of a similar name, and also
a qube able to fulfil that role, because it provides the necessary interface(s), and also
a qube which is actually doing all that.
To make clear: I greatly prefer ‘qube’ to both ‘VM’ and ‘domain’. 100% behind that, as both those terms have other meanings. I have a soft spot for dom0, with the connotation of “Domina” or “Dominus” - the big boss.
Lastly, by way of qualification:
For me, “interface qube” is a perfect term for the exact analogue of the audio one, except that I find the “interface” part to be a very weak and imprecise proxy for what the rest of the world calls “GUI”, which seems much closer to the true nature of the role.