Consider removing dom0 from a VM list in Qubes Manager

[marmarek]

It's a source of lot of confusion:

• #1367 (Grey-out "Add/remove app shortcuts for this VM" when hovering over dom0 in QVMM)
• #1015 (Consider changing "dom0" to "qubes" for better UX)
• #1165 (implement dom0 -> right click -> VM settings / easy way to configure updatevm setting)

The only things applicable for dom0 are:

• installing updates (which in fact is done totally different than for a VM)
• showing CPU/RAM usage (which actually doesn't work: #1120)

All other options doesn't apply there. Independently there should be an easier option to access global settings (currently only available through menu).
@bnvk

[bnvk]

I definitely think this is the right direction UX wise- to remove dom0 from the VM Manager, as it's such an outlier both in concept + available user actions.

The question then is- where do we put the few actions pertaining to dom0 that makes most sense? My instinct is one of the following:

• Put the couple actions (Update dom0, View Logs) in the far right of topbar of VM Manager
• Under the System dropdown menu, but use that far right space to make a Update System show up when an update exists

[bnvk]

I definitely think this is the right direction UX wise- to remove dom0 from the VM Manager, as it's such an outlier both in concept + available user actions.

The question then is- where do we put the few actions pertaining to dom0 that makes most sense? My instinct is one of the following:

• Put the couple actions (Update dom0, View Logs) in the far right of topbar of VM Manager
• Under the System dropdown menu, but use that far right space to make a Update System show up when an update exists

[marmarek]

I think the second option is better - there are already IMHO too much buttons there. Maybe we should even remove some of them (first candidates: keyboard layout, remove VM)?

[marmarek]

I think the second option is better - there are already IMHO too much buttons there. Maybe we should even remove some of them (first candidates: keyboard layout, remove VM)?

[mfc]

definitely agree with removing dom0 from VM list.

maybe for the topbar, we should only have listed actions that are global in nature (i.e. no actions that are specific to VMs (except start, pause, stop). users can already right-click on a particular VM or use the VM dropdown for VM-specific actions. I think start, pause, stop are common and administrative enough in nature they could stay.

[mfc]

definitely agree with removing dom0 from VM list.

maybe for the topbar, we should only have listed actions that are global in nature (i.e. no actions that are specific to VMs (except start, pause, stop). users can already right-click on a particular VM or use the VM dropdown for VM-specific actions. I think start, pause, stop are common and administrative enough in nature they could stay.

[bnvk]

there are already IMHO too much buttons there. Maybe we should even remove some of them

Yes. I agree. Both "Keyboard layout" and "remove VM" are low hanging fruits to nuke.

maybe for the topbar, we should only have listed actions that are global in nature (i.e. no actions that are specific to VMs (except start, pause, stop)

That might be a bit too drastic. I don't think relying on users knowing to "right click" on items is particularly the right approach- especially with new fangled / unusual systems like Qubes. If anything, more explicit "buttons" should be included on each VM item, so that necessary actions are more explicit. However, this starts to get out of hand and needs to be done with the right balance so we don't end up with similar issues like we have.

My suggestion for the 3.1 release is that I give some thought to re-thinking the buttons in the current topbar of the VM Manager.

Beyond that explore drastic refactoring of the VM Manager in general. I sketched some of these ideas with @rootkovska in DC and she was very keen on the concepts. Losely explained- I'm thinking about splitting them up into different "types" of VM managers (templates, networking, apps).

[bnvk]

there are already IMHO too much buttons there. Maybe we should even remove some of them

Yes. I agree. Both "Keyboard layout" and "remove VM" are low hanging fruits to nuke.

maybe for the topbar, we should only have listed actions that are global in nature (i.e. no actions that are specific to VMs (except start, pause, stop)

That might be a bit too drastic. I don't think relying on users knowing to "right click" on items is particularly the right approach- especially with new fangled / unusual systems like Qubes. If anything, more explicit "buttons" should be included on each VM item, so that necessary actions are more explicit. However, this starts to get out of hand and needs to be done with the right balance so we don't end up with similar issues like we have.

My suggestion for the 3.1 release is that I give some thought to re-thinking the buttons in the current topbar of the VM Manager.

Beyond that explore drastic refactoring of the VM Manager in general. I sketched some of these ideas with @rootkovska in DC and she was very keen on the concepts. Losely explained- I'm thinking about splitting them up into different "types" of VM managers (templates, networking, apps).

[adrelanos]

Michael Carbone:

definitely agree with removing dom0 from VM list.

Yes, because dom0 isn't a VM.

[adrelanos]

Michael Carbone:

definitely agree with removing dom0 from VM list.

Yes, because dom0 isn't a VM.

[marmarek]

On Tue, Nov 10, 2015 at 07:06:50AM -0800, Brennan Novak wrote:

My suggestion for the 3.1 release is that I give some thought to re-thinking the buttons in the current topbar of the VM Manager.

If we're going to do anything with this for R3.1, it needs to be done
NOW. We're (hopefully) really close to feature freeze - something about
two weeks. Brennan, are you planning to implement any of this? I'm
afraid I'll not make it before feature freeze.

Beyond that explore drastic refactoring of the VM Manager in general. I sketched some of these ideas with @rootkovska in DC and she was very keen on the concepts. Losely explained- I'm thinking about splitting them up into different "types" of VM managers (templates, networking, apps).

Offtopic: while at it, Qubes Manager needs internals rewrite - it has
terrible architecture. Something probably for Qubes R4.1...

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?

[marmarek]

On Tue, Nov 10, 2015 at 07:06:50AM -0800, Brennan Novak wrote:

My suggestion for the 3.1 release is that I give some thought to re-thinking the buttons in the current topbar of the VM Manager.

If we're going to do anything with this for R3.1, it needs to be done
NOW. We're (hopefully) really close to feature freeze - something about
two weeks. Brennan, are you planning to implement any of this? I'm
afraid I'll not make it before feature freeze.

Beyond that explore drastic refactoring of the VM Manager in general. I sketched some of these ideas with @rootkovska in DC and she was very keen on the concepts. Losely explained- I'm thinking about splitting them up into different "types" of VM managers (templates, networking, apps).

Offtopic: while at it, Qubes Manager needs internals rewrite - it has
terrible architecture. Something probably for Qubes R4.1...

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?

[marmarek]

On Tue, Nov 10, 2015 at 07:07:41AM -0800, Patrick Schleizer wrote:

Yes, because dom0 isn't a VM.

Technically it is, just privileged one. But it doesn't mater.

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?

[marmarek]

On Tue, Nov 10, 2015 at 07:07:41AM -0800, Patrick Schleizer wrote:

Yes, because dom0 isn't a VM.

Technically it is, just privileged one. But it doesn't mater.

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?

[bnvk]

Brennan, are you planning to implement any of this?

If feature freeze is two weeks, I don't think I can manage to implement this by then + as well as making headway on the public facing website work that is long overdue.

[bnvk]

Brennan, are you planning to implement any of this?

If feature freeze is two weeks, I don't think I can manage to implement this by then + as well as making headway on the public facing website work that is long overdue.

[mfc]

at minimum all we need is to remove the dom0 listing and put a menu item under System for updating adminVM (assuming the updating dom0 by GUI actually works). And if updating dom0 by GUI doesn't work, have the link open a terminal in dom0 that runs sudo qubes-dom0-update.

[mfc]

at minimum all we need is to remove the dom0 listing and put a menu item under System for updating adminVM (assuming the updating dom0 by GUI actually works). And if updating dom0 by GUI doesn't work, have the link open a terminal in dom0 that runs sudo qubes-dom0-update.

[rootkovska]

I think it's still useful to show mem/cpu stats for Dom0. Until we completely rewrite Qubes Manager (which is not gonna happen for 3.1, probably only for 4 when we also migrate to Gnome), I would recommend leaving Dom0 there. Perhaps not allow to select it. Also perhaps rename it as Admin/GUI?

Speaking of mem stats: the total sum of all mem allocated to all the VMs (incl. Dom0) does not (usally) equal the total available system memory. We should consider to display also the total amount of DRAM (as well as total used/free) somewhere in the manager as well, perhaps in the status bar?

[rootkovska]

I think it's still useful to show mem/cpu stats for Dom0. Until we completely rewrite Qubes Manager (which is not gonna happen for 3.1, probably only for 4 when we also migrate to Gnome), I would recommend leaving Dom0 there. Perhaps not allow to select it. Also perhaps rename it as Admin/GUI?

Speaking of mem stats: the total sum of all mem allocated to all the VMs (incl. Dom0) does not (usally) equal the total available system memory. We should consider to display also the total amount of DRAM (as well as total used/free) somewhere in the manager as well, perhaps in the status bar?

[mfc]

I think it's still useful to show mem/cpu stats for Dom0

well CPU stats from dom0 don't work #1120, so that reduces the usefulness of listing it to the mem stats. which isn't that useful except as a proxy for free memory (whether you can open a new VM or not). for me somewhere around 2000 MB MEM for dom0 means no more opening new VMs due to lack of free memory, but as a user I always have to try anyway since sometimes it works with less free memory and sometimes not.

so I would still suggest not having the dom0 listing. if we want to have a free memory listing somewhere that could be helpful, especially if we could communicate a user that they have enough memory to open approximately 2 more qubes or something.

[mfc]

I think it's still useful to show mem/cpu stats for Dom0

well CPU stats from dom0 don't work #1120, so that reduces the usefulness of listing it to the mem stats. which isn't that useful except as a proxy for free memory (whether you can open a new VM or not). for me somewhere around 2000 MB MEM for dom0 means no more opening new VMs due to lack of free memory, but as a user I always have to try anyway since sometimes it works with less free memory and sometimes not.

so I would still suggest not having the dom0 listing. if we want to have a free memory listing somewhere that could be helpful, especially if we could communicate a user that they have enough memory to open approximately 2 more qubes or something.

[rootkovska]

If we removed dom0 (aka 'admin') now, and then introduced gui domain in Qubes 4, then everybody would think it's reintroduction of the dom0 (but this won't be true anymore). Also: since we keep displaying other "service" VMs, such as net, firewall, etc, then I see no reason why treat dom0 specially and hide it? Perhaps better would be to have a (default?) view mode which would be showing only user appVMs, and hide all the service VMs (now including the dom0)?

[rootkovska]

If we removed dom0 (aka 'admin') now, and then introduced gui domain in Qubes 4, then everybody would think it's reintroduction of the dom0 (but this won't be true anymore). Also: since we keep displaying other "service" VMs, such as net, firewall, etc, then I see no reason why treat dom0 specially and hide it? Perhaps better would be to have a (default?) view mode which would be showing only user appVMs, and hide all the service VMs (now including the dom0)?

[marmarek]

The main reason for removing dom0 is having totally different actions
and properties than any other VM (including service ones). So such hide
option would not solve this problem (but may be a good idea anyway).

So I guess the general answer is: do not remove, maybe rename it. Right?
Which means that the tickets mentioned at the beginning still needs to
be fixed.

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?

[marmarek]

The main reason for removing dom0 is having totally different actions
and properties than any other VM (including service ones). So such hide
option would not solve this problem (but may be a good idea anyway).

So I guess the general answer is: do not remove, maybe rename it. Right?
Which means that the tickets mentioned at the beginning still needs to
be fixed.

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?

[bnvk]

I would recommend leaving Dom0 there. Perhaps not allow to select it.

It's usually bad form to have an item in a list that is grayed
out / non-selectable as a user goes through questions (in their
head) like "why can't I select, this one" and "why is this one
different than the others" which are mildly frustrating and lead
to feelings that has done something wrong.

If we removed dom0 (aka 'admin') now, and then introduced gui domain in Qubes 4, then everybody would think it's reintroduction of the dom0 (but this won't be true anymore)

given the idea of splitting up "types" of VMs (networking,
templates, apps) like we discussed in DC, the changes I'm
imagining will be drastic enough that I don't think people we
think we are reintroducing dom0

since we keep displaying other "service" VMs, such as net, firewall, etc, then I see no reason why treat dom0 specially and hide it

as @marmarek points out "dom0 is having totally different actions
and properties" which is the spirit of the first point I am
making- items in a visually repeating lists should be uniform in
terms of available UX actions per item

So I guess the general answer is: do not remove, maybe rename it. Right?

simply renaming dom0 to admin is a nice simple tweak and what
I was aiming for with issue #1015

[bnvk]

I would recommend leaving Dom0 there. Perhaps not allow to select it.

It's usually bad form to have an item in a list that is grayed
out / non-selectable as a user goes through questions (in their
head) like "why can't I select, this one" and "why is this one
different than the others" which are mildly frustrating and lead
to feelings that has done something wrong.

If we removed dom0 (aka 'admin') now, and then introduced gui domain in Qubes 4, then everybody would think it's reintroduction of the dom0 (but this won't be true anymore)

given the idea of splitting up "types" of VMs (networking,
templates, apps) like we discussed in DC, the changes I'm
imagining will be drastic enough that I don't think people we
think we are reintroducing dom0

since we keep displaying other "service" VMs, such as net, firewall, etc, then I see no reason why treat dom0 specially and hide it

as @marmarek points out "dom0 is having totally different actions
and properties" which is the spirit of the first point I am
making- items in a visually repeating lists should be uniform in
terms of available UX actions per item

So I guess the general answer is: do not remove, maybe rename it. Right?

simply renaming dom0 to admin is a nice simple tweak and what
I was aiming for with issue #1015

[rootkovska]

Let's do the dom0->admin rename for now. Lets postpone the discussion on whether to get rid of this from the Manager's list until R4, ok?

[rootkovska]

Let's do the dom0->admin rename for now. Lets postpone the discussion on whether to get rid of this from the Manager's list until R4, ok?

[marmarek]

On Fri, Nov 13, 2015 at 07:27:59AM -0800, Joanna Rutkowska wrote:

Let's do the dom0->admin rename for now. Lets postpone the discussion on whether to get rid of this from the Manager's list until R4, ok?

Should it be "admin", "Admin", "AdminVM" or something else? Should the
rename be global (for example qvm-ls also would list the new name), or
Qubes Manager only?

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?

[marmarek]

On Fri, Nov 13, 2015 at 07:27:59AM -0800, Joanna Rutkowska wrote:

Let's do the dom0->admin rename for now. Lets postpone the discussion on whether to get rid of this from the Manager's list until R4, ok?

Should it be "admin", "Admin", "AdminVM" or something else? Should the
rename be global (for example qvm-ls also would list the new name), or
Qubes Manager only?

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?

[rootkovska]

Since all the (default) domains are currently all lower-case strings, the same should be for the "admin", I think. Also, it's only reasonable for maintaining consistency between the names used in the Manager and qvm-tools.

[rootkovska]

Since all the (default) domains are currently all lower-case strings, the same should be for the "admin", I think. Also, it's only reasonable for maintaining consistency between the names used in the Manager and qvm-tools.

[marmarek]

Hmm, I've done grep 'dom0'. Renaming it internally probably will break
all the things... There are few places where we use it for some special
cases (those places probably can be fixed), but there are also
places where toolstack (libvirt/libxl) requires this name. And probably
more where vm.name reference is supposed to just work, even for dom0
(grep will not find those).
Some examples of our things:

• qubes-dom0-update tool - renaming it would require at least
  documentation update, but also will be pain for users used to type
  qubes-dom0-update
• backup format refer to dom0-home - renaming it would require
  additional, tricky code to handle restoring backups made on older
  systems
• some package names contains dom0 - packages renames are tricky on
  update
• we'd need to prevent a VM being named "dom0" anyway, because that would
  conflict with real "dom0"
• qrexec policies refer to "dom0", also VM tools uses target VM name
  "dom0" for some services - like qubes.NotifyUpdates

Also having qvm-ls listing "admin", but xl list listing "dom0" would
be confusing.

So I think we should either go with only slight change - Qubes Manager
only. Or don't change at all (and later maybe remove from Qubes Manager).

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?

[marmarek]

Hmm, I've done grep 'dom0'. Renaming it internally probably will break
all the things... There are few places where we use it for some special
cases (those places probably can be fixed), but there are also
places where toolstack (libvirt/libxl) requires this name. And probably
more where vm.name reference is supposed to just work, even for dom0
(grep will not find those).
Some examples of our things:

• qubes-dom0-update tool - renaming it would require at least
  documentation update, but also will be pain for users used to type
  qubes-dom0-update
• backup format refer to dom0-home - renaming it would require
  additional, tricky code to handle restoring backups made on older
  systems
• some package names contains dom0 - packages renames are tricky on
  update
• we'd need to prevent a VM being named "dom0" anyway, because that would
  conflict with real "dom0"
• qrexec policies refer to "dom0", also VM tools uses target VM name
  "dom0" for some services - like qubes.NotifyUpdates

Also having qvm-ls listing "admin", but xl list listing "dom0" would
be confusing.

So I think we should either go with only slight change - Qubes Manager
only. Or don't change at all (and later maybe remove from Qubes Manager).

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?

[bnvk]

Since all the (default) domains are currently all lower-case strings, the same should be for the "admin", I think

Yah. Fully agree, just admin for uniformity!

I think we should either go with only slight change - Qubes Manager only. Or don't change at all (and later maybe remove from Qubes Manager).

Ah, makes sense so many things would break with the change. Hrm.
I think simple rename in Qubes Manager now is a slight
improvement. And later when rethinking that / removing it sounds
pretty good!

[bnvk]

Since all the (default) domains are currently all lower-case strings, the same should be for the "admin", I think

Yah. Fully agree, just admin for uniformity!

I think we should either go with only slight change - Qubes Manager only. Or don't change at all (and later maybe remove from Qubes Manager).

Ah, makes sense so many things would break with the change. Hrm.
I think simple rename in Qubes Manager now is a slight
improvement. And later when rethinking that / removing it sounds
pretty good!

[andrewdavidwong]

In Qubes Manager, under the Template column, the line for dom0 already says AdminVM. It looks like this:

Name	State	Template
dom0	o	AdminVM

If you rename dom0 to admin, the result will look like this:

Name	State	Template
admin	o	AdminVM

I really don't see how that constitutes a significant improvement. In fact, it strikes me as somewhat redundant, because I already know that it's the AdminVM by just looking at Qubes Manager. Calling it "admin" provides me with zero new information in this case.

[andrewdavidwong]

In Qubes Manager, under the Template column, the line for dom0 already says AdminVM. It looks like this:

Name	State	Template
dom0	o	AdminVM

If you rename dom0 to admin, the result will look like this:

Name	State	Template
admin	o	AdminVM

I really don't see how that constitutes a significant improvement. In fact, it strikes me as somewhat redundant, because I already know that it's the AdminVM by just looking at Qubes Manager. Calling it "admin" provides me with zero new information in this case.

[andrewdavidwong]

Maybe this is what you want instead:

Name	State	Template
admin	o	n/a

This would be more accurate, since it doesn't make sense to talk about dom0 being based on a template.

On a related note, TemplateVMs say "TemplateVM" under the Template column. Again, this is strictly speaking inaccurate, since templates can't be nested. TemplateVMs can't (currently) be based on other TemplateVMs. Hence, this column should say "n/a."

In general, there is a bad habit in Qubes Manager of sticking information into a column where it does not belong as a way to convey information to the user which ought to be conveyed in a different way. VM types are conveyed to users in the leftmost column as an icon (with hover text). Therefore, this information should not appear a second time under the Template column, where it makes no sense. If you want to have the text of a VM type instead of just an icon (which would be a good idea), then put it in the appropriate column (the leftmost column for VM type).

[andrewdavidwong]

Maybe this is what you want instead:

Name	State	Template
admin	o	n/a

This would be more accurate, since it doesn't make sense to talk about dom0 being based on a template.

On a related note, TemplateVMs say "TemplateVM" under the Template column. Again, this is strictly speaking inaccurate, since templates can't be nested. TemplateVMs can't (currently) be based on other TemplateVMs. Hence, this column should say "n/a."

In general, there is a bad habit in Qubes Manager of sticking information into a column where it does not belong as a way to convey information to the user which ought to be conveyed in a different way. VM types are conveyed to users in the leftmost column as an icon (with hover text). Therefore, this information should not appear a second time under the Template column, where it makes no sense. If you want to have the text of a VM type instead of just an icon (which would be a good idea), then put it in the appropriate column (the leftmost column for VM type).

[Rudd-O]

I like it there. Please don't take muh dom0s away :-)

[Rudd-O]

I like it there. Please don't take muh dom0s away :-)

[mfc]

When dom0 is removed from QVM list, available updates should to be notified to the user not within QVM but in a system notification/icon in system tray, as is done in vanilla KDE. This icon stays in the sys-tray until the user updates, it is not a momentary notification.

This might be something worth implementing for when updates to any templates or dom0 are found by the system.

[mfc]

When dom0 is removed from QVM list, available updates should to be notified to the user not within QVM but in a system notification/icon in system tray, as is done in vanilla KDE. This icon stays in the sys-tray until the user updates, it is not a momentary notification.

This might be something worth implementing for when updates to any templates or dom0 are found by the system.

[evadogstar]

Please, When dom0 will be implemented as menu with some actions (Update dom0, View Logs) do not forget about "Run terminal" action.

I'm already wrote at QM UX ticket, that it will be fine to have new Qubes Manager with some icon near AppVM name to open application list with left click on it and run application from the menu. Maybe some users will have the ability to forget about "Start Menu" and only use QM for all tasks.

Advantages of local "run menu" for each VM is that it can be flexible, easy support vs. KDE, XFCE (from development POV) and easy customization(from user POV).

[evadogstar]

Please, When dom0 will be implemented as menu with some actions (Update dom0, View Logs) do not forget about "Run terminal" action.

I'm already wrote at QM UX ticket, that it will be fine to have new Qubes Manager with some icon near AppVM name to open application list with left click on it and run application from the menu. Maybe some users will have the ability to forget about "Start Menu" and only use QM for all tasks.

Advantages of local "run menu" for each VM is that it can be flexible, easy support vs. KDE, XFCE (from development POV) and easy customization(from user POV).

[Rudd-O]

Run terminal would be great. Just run through a list of konsole and xterm, running the first that is available and a+x.

[Rudd-O]

Run terminal would be great. Just run through a list of konsole and xterm, running the first that is available and a+x.

[marmarta]

Given that Qubes Manager has been changed significantly, split into widgets for everyday use and the tool for bigger management tasks, I think this can be closed.

[marmarta]

Given that Qubes Manager has been changed significantly, split into widgets for everyday use and the tool for bigger management tasks, I think this can be closed.