Stop using abbreviations for Whonix templates

[mfc]

we need to stop using non-intuitive abbreviations, which are:

• confusing for new users
• bad for localization/translation (directly or in documentation)

whonix-ws -> whonix-workstation
whonix-gw -> whonix-gateway

[marmarek]

I don't think it is great idea. Those VMs are not actually
whonix-workstation or whonix-gateway. Those are templates of them. It
requires more thinking. Maybe templates should be hidden by default
(renamed by your suggestion)? But then there should be easy and
intuitive way for doing updates and installing new software...

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?

[mfc]

I agree the proposed names are bad, they should highlight that they are templates (maybe whonix-workstation-template etc?). What about the underlying idea of reducing use of abbreviations?

[adrelanos]

Perhaps all TemplateVMs should be prefixed with 'template-'?

Looping in @bnvk. How does this ticket integrate with what you had in
mind for the QVMM revamp / alternative gui?

[andrewdavidwong]

I like @adrelanos's suggestion of prefixing all TemplateVMs. (Personally, I would prefer something like tmpl- over template- because my template names are already too long.)

Prefixing is much better than postfixing in this case, because it will result in all the templates sorting together lexically.

[mfc]

(Personally, I would prefer something like tmpl- over template- because my template names are already too long.)

No, no abbreviations. We should have tab-complete to make typing such things in terminal faster. Or have no abbreviations and have clearer separation of different types of VMs (template, system, app) clearer in the VM Manager.

I don't think it is great idea. Those VMs are not actually whonix-workstation or whonix-gateway. Those are templates of them.

You can't argue whonix-ws -> whonix-workstation is bad because people will think they are not templates, that is an orthogonal problem to this and is a problem with all templates. e.g. if that is a problem, it already exists, and this does not address that problem.

I continue to run into issues with these abbreviations at trainings, whether they are native english speakers or not. The worst part is that whonix-ws and whonix-gw are only one letter apart >:(

[adrelanos]

What's the status of this ticket?

@marmarek

I don't think it is great idea.

At this point, considered rejected as in "won't fix" or "won't do"?

Or waiting for more discussion / thinking / input?

Or is it dependent on the outcome of #1776?

---

(I personally don't have any strong opinion here either way and would to refer to advice by usability designers.)

[DemiMarie]

@ninavizz I imagine this is your call

[ninavizz]

Yes @adrelanos I would qualify this as dependent on #1776. HOWEVER, I also see #1776 as nearing completion.

For the latest Whonix release, I'd prefer we not change anything, in the interest of not creating UX churn. For 4.2 I see #1776 being resolved, as the new app menu design already does that (and I suspect Qubes Manager can be tweaked to meet the needs of #1776 by then, too).

— EDIT —

This oyster being Marek's, it's ultimately his call... tho I appreciate the callout, Demi! The above is my recommendation. :)

[andrewdavidwong]

Isn't this just a specific instance of #1776? What's the point of having both open?

[mfc]

I don't see this issue at all dependent to #1776.

the equivalent of this issue is if we named the debian or fedora minimal templates to be debian-11-mn or fedora-11-ml. this issue is focused on a behavior that is not system-wide, it is specific to the whonix templates and has no logical consistency with the rest of our namings of templates.

all this issue is asking, is -- just as we spell out minimal for the minimal templates -- to spell out what the different whonix templates are. so expand "gw" to "gateway" and "ws" to "workstation". that is all.

this can be done independently of #1776 and we could even not implement #1776 and still fix this issue.

[ninavizz]

@mfc Ok, so—two things. One, your point about localization and multi-lingual users is totally legit. "disp-89068" as an example, makes no sense to users that don't speak English, or do speak English but don't quickly intuit that "disp" is an abbreviation of "disposable."

With 4.1 we do have clearer icons to delineate what is a template, vs what is disposable, vs what is an app qube, vs what is a service qube. And yet Whonix is... (winces) a Service that requires Templates, and may not even be seen as a Service by the system. BUT, Whonix Templates will still get Template icons per #5676

For users using the new app menu, App qubes and Templates will further never be shown in the same view, which will help keep users from going to open a Template when they want to open an App qube.

Given the icons will help disambiguate App qubes from Templates, would you feel satisfied with whonix-gateway and whonix-workstation as qube names for Whonix 16?

[ninavizz]

@andrewdavidwong I think this issue has pivoted to discussing Template name suffixes, not prefixes; but the abbreviations issue cited in the title, began as a discussion around prefixes. Both stink, tbh; but also need a longer-term solution (like a parenthetical or something). I dunno. It still feels like this is not yet solved for.

[mfc]

correct this issue is not about the prefixes and is not something that icons or ordering can help solve -- all of that is in #1776.

if we follow the naming convention of the minimal templates which is qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>-minimal then the upcoming Whonix 16 templates should be named in the repos:

• qubes-template-whonix-16-workstation
• qubes-template-whonix-16-gateway

which would appear when installed to the user as:

• whonix-16-workstation
• whonix-16-gateway

or if we consider the workstation and gateway to be separate distributions (our current practice, i'm not sure why), then we can switch the release number and workstation/gateway as we currently do. but i think the above is cleaner & clearer.

[andrewdavidwong]

Thanks for the explanation. I understand now.

[marmarek]

Ok, indeed with clearer distinction what is a template and what is not (new menu, new icons, new layout in the manager etc), I think we can go ahead with this rename.
Some things to keep in mind when choosing names are:

• qube name needs to be system-wide unique (you can't have App qube and Template qube with the same name)
• qube names are limited to 31 characters

But in this case, none of the above is a concern. Should be good.

@adrelanos do you want to go with this with Whonix 16 already, or is it too late for such change, and should we schedule it for Whonix 17?

[adrelanos]

correct this issue is not about the prefixes and is not something that icons or ordering can help solve -- all of that is in #1776.

if we follow the naming convention of the minimal templates which is qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>-minimal then the upcoming Whonix 16 templates should be named in the repos:

• qubes-template-whonix-16-workstation
• qubes-template-whonix-16-gateway

which would appear when installed to the user as:

• whonix-16-workstation
• whonix-16-gateway

I would prefer the long notation qubes-template-whonix-16-workstation, qubes-template-whonix-16-gateway for all places.

And I'd suggest to avoid the short notation whonix-16-workstation, whonix-16-gateway for templates. Any icons, tables are useful but for blind users or otherwise people who easily overlook such things or who mostly rely on textual information that notation can be confusing. While the long notation is unambiguous.

...but I am missing QVMM R4.1 innovations. Maybe hard to get it wrong there.

@adrelanos do you want to go with this with Whonix 16 already, or is it too late for such change, and should we schedule it for Whonix 17?

Might cause confusion if some have Whonix 16 in the legacy notation and some not if we change that now. Not sure.

Doing this for Whonix 17 seems safe. Pull requests would be useful with a note to merge these for Whonix 17 so this doesn't have to be invented under pressure when Whonix 17 release time comes close or gets forgotten by then.

[andrewdavidwong]

correct this issue is not about the prefixes and is not something that icons or ordering can help solve -- all of that is in #1776.

if we follow the naming convention of the minimal templates which is qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>-minimal then the upcoming Whonix 16 templates should be named in the repos:

• qubes-template-whonix-16-workstation

• qubes-template-whonix-16-gateway

which would appear when installed to the user as:

• whonix-16-workstation

• whonix-16-gateway

I would prefer the long notation qubes-template-whonix-16-workstation, qubes-template-whonix-16-gateway for all places.

That's the naming pattern for template packages, not qubes.

Now you're talking about changing the naming pattern for all template qubes, not just Whonix templates.

Also, the first name is longer than 31 characters.

And I'd suggest to avoid the short notation whonix-16-workstation, whonix-16-gateway for templates. Any icons, tables are useful but for blind users or otherwise people who easily overlook such things or who mostly rely on textual information that notation can be confusing. While the long notation is unambiguous.

...but I am missing QVMM R4.1 innovations. Maybe hard to get it wrong there.

@adrelanos do you want to go with this with Whonix 16 already, or is it too late for such change, and should we schedule it for Whonix 17?

Might cause confusion if some have Whonix 16 in the legacy notation and some not if we change that now. Not sure.

But no one has Whonix 16 stable yet, because it doesn't exist yet. Changes to Whonix 16 unstable are fine, as it's unstable. (Note: I'm not saying you should or shouldn't do it. I'm only addressing this specific point.)

Doing this for Whonix 17 seems safe. Pull requests would be useful with a note to merge these for Whonix 17 so this doesn't have to be invented under pressure when Whonix 17 release time comes close or gets forgotten by then.

[ninavizz]

@mfc My comments about icons, are relevant to whether or not the word "template" is included in the name of the qube. TY @andrewdavidwong for clarifying that Michael was in fact describing packages and not qube names.

Question for everyone: Why is it normal/customary in Qubes to leave old versions of things on a machine, when we have new versions? Like, is there a reason to have multiple versions of Whonix on a machine, other than "It doesn't un-install old versions"?

I'd like to develop some method for tracking distro versions other than forcing them to be included in the name. At some point, not as a part of this ticket. Yes, I'm going to be chatting with @marmarta about including build/version numbers for templates in their submenus from the App Menu, and for Qubes Manager a unique UIs (variation on the existing) will also need to be developed). On the CLI some UX things will likely need to be added.

[andrewdavidwong]

Question for everyone: Why is it normal/customary in Qubes to leave old versions of things on a machine, when we have new versions? Like, is there a reason to have multiple versions of Whonix on a machine, other than "It doesn't un-install old versions"?

Some users like to have multiple templates corresponding to multiple releases of an OS installed at the same time (sometimes even EOL releases). Users have a wide variety of reasons for this practice. It would be very bad if we automatically deleted any of their templates without asking simply because we assumed they were "old," and it would probably fail a lot of the time anyway, since there would probably be app qubes dependent on those templates. However, it might make sense to prompt users to ask them whether they'd like us to delete an old template that we automatically detect is no longer in use (or inform them that the old one is still in use, possibly unintentionally), e.g., as a final cleanup step after installing a new template version.

[brendanhoar]

Succinctly: a user can customize a qubes-installed template. Deleting a template loses those customizations.

Customization ranges from the common use case of installing additional software to...changing system configuration to...a universe of things.

A replacement template ("newly built version" not just updates to existing one) won't have those customizations and automatically deleting an old template loses those customizations.

B

[andrewdavidwong]

Yeah. Basically, templates are (or, more precisely, can be) user data, and you never mess with user data.

[marmarek]

I've opened remaining PRs related to template renaming. They are not tested yet, I'll build test installer and try it out.

[marmarek]

Qubes dom0 appmenu is empty for the R4.2 testing Template. Any renaming required for that?

Appmenu should work regardless, something went wrong. Maybe it's about "bullseye" in directory names at https://github.com/whonix/qubes-template-whonix ?

[adrelanos]

Also https://github.com/Whonix/qubes-template-whonix/blob/master/builder.conf needs to be updated? I can do that now just in case.

But it seems that's not a big ideal? Is the builder.conf no longer required?

[marmarek]

But it seems that's not a big ideal? Is the builder.conf no longer required?

I think it's used for manual build using qubes-builder(v1). Neither builderv2 nor official builds with legacy qubes-builder use this file (the latter use https://github.com/QubesOS/qubes-template-configs/blob/master/R4.1/templates-community/whonix-16.conf).

[adrelanos]

Qubes dom0 appmenu is empty for the R4.2 testing Template. Any renaming required for that?

Appmenu should work regardless, something went wrong. Maybe it's about "bullseye" in directory names at https://github.com/whonix/qubes-template-whonix ?

Quite likely. It's fixed in git. Will re-check in the next template build once #8330 was resolved (QubesOS/qubes-builder-debian#73).

But it seems that's not a big ideal? Is the builder.conf no longer required?

I think it's used for manual build using qubes-builder(v1). Neither builderv2 nor official builds with legacy qubes-builder use this file (the latter use https://github.com/QubesOS/qubes-template-configs/blob/master/R4.1/templates-community/whonix-16.conf).

Alright. I'll remove that file now.

[marmarek]

Three PRs linked above are tested now.

[marmarek]

This rename is done now in R4.2.