dom0 UX visibility issues - system state, free space, per-vm used storage, CPU, RAM, attachments, virt_type, pool & tags

[na--]

Qubes OS version:

R4.0 RC2

Affected TemplateVMs:

none (dom0 issue)

---

Expected behavior:

Have an easy way to see the accurate current system state:

• how much free space there is in the used system drives(s)
• how much space each VM and template uses, preferably with the ability to sort them
• currently used CPU and memory for active VMs, also sortable
• other properties like virt_type, kernel, used storage pool, tags, etc. for every VM without having to muck about individually with qvm-prefs or qubes.xml
• one-second answers for questions like "is my mic/webcam/external drive attached to a vm?"
• easy answers to questions like "What are the VMs that use the debian/archlinux/etc. template?", "Which VMs are connected to the sys-whonix gateway?", "Which VMs use kernel 4.13?", etc. (i.e. filtering/sorting/querying by certain VM properties)

Ideally, the above should be easily achievable both via the GUI (for normal users) and via the CLI (for scripting and CLI/advanced users).

Actual behavior:

Most of the things above are far more difficult than they should be. I wrote about my issues with determining the free space when using LVM thin provisioning in another issue. Other UX issues (at least for me) will be discussed below.

General notes:

I'm very slowly adjusting to the lack of qubes manager in 4.0, but it has been a huge usability drop for me. It was a single place that showed the current accurate system state and allowed me to modify it and perform all sorts of actions very easily. Right now there is simply no alternative.

qvm-ls is a very poor replacement of the old qubes manager: it's a CLI tool (unsuitable for linux newbies), it does not show current CPU and RAM usage and does not allow sorting. It also lacks some information like virt_type, kernel, storage pool and tags. RAM usage can be found via xl list, and information for disk and usb attachments is in other CLI tools (qvm-block, qvm-usb), as it should be, but that makes system information gathering cumbersome. qvm-prefs and qvm-tags show some things that are not present in qvm-ls, but lack others (storage pool for VM).

The new system tray widgets for VMs and attachments show only a fraction of the needed information, are somewhat broken (1, 2) and have somewhat poor UX, at least in my view (more on this below). Right now gathering the current system information from one source is impossible, especially via the GUI.

Current GUI shortcomings and missing features that I see:

• Overall system visibility is very poor:
  • I already mentioned the issues with missing disk & CPU usage and lack of sorting, but that's just the (most annoying) tip of the iceberg :)
  • There is no GUI way to answer most of the questions from the "Expected behavior" section above and the few questions that can be answered (which VMs use certain templates/kernels/netvms/etc.) involve manually opening the settings dialogs for each VM
  • Even determining whether the microphone/webcam/external drive is currently attached to a VM is more difficult than it should be. I have to click on a small icon, navigate to a specific row and look at a column of icons to try and spot a small "Eject CD" icon among other small plus icons. Contrast this with the previous way when you had a specific empty column for the microphone status and you can immediately and effortlessly see whether it was attached and to which VMs. Right now I have to remember to detach it, there is no visible indicator that something is attached unless I go and look for it.
• Actions are ultra scattered: create vm in one menu, global qubes settings in another menu, per-vm settings are in each appvm menu, drive/usb/mic attachment is in small systray widget and vm shutdown is in another buggy systray widget; this kind of makes sense and the arguments for it in #2132 are very good - I just think that these actions in different menus would've better been in addition to them being present in a centralized qube manager, not as a total replacement of it
• Other actions are totally missing: there is no GUI backup/restore, no way to kill, restart, pause and clone a VM from the GUI, view the logs of running VMs is only shown while they start (and even then does not work); starting a VM without running a particular application is also impossible from the GUI

Sorry if this looks a bit like a rant or criticism, it's not. I'm a long time Qubes user and have no intention of using something else any time soon, or even reverting to 3.2 if I can help it :) If there's some consensus, I would love to help with improvements to the GUI, even though my python skills are more than a bit rusty. I realize that the old qubes manager had to be scrapped or rewritten because of the changes in the internals, but is there a chance something like it could be resurrected or the current widgets made more informative, functional and configurable?

---

Related issues:

#2132 seems to be the issue in which the removal of the qubes manager was decided and some of the new GUI elements were prototyped
#3240 where I mentioned my storage issues in more detail

[qubesuser]

I agree.

My suggestion would be to write a bunch of applications with a similar UI, one for each concern.

This separation would essentially mimic the way traditional operating systems manage resources, but one could also have a single application with multiple tabs, and perhaps a way to look at a given VM in other apps/tabs (e.g. in Windows you use Explorer/WinDirStat to look at storage, Task Manager for CPU/memory/I/O usage, Network control panel for network, Device Manager for devices).

Tree views would become list views when sorted.

Running VMs
Add a new "Qubes Task Manager" that would show, in a list view, running VMs, their CPU, memory, network and disk I/O usage, as percentages and graphs (only update the graphs when the window is visible!), and allows to easily launch System Monitor and Terminal in the VMs

Change to the Qubes domains tray icon to open it on double click or when clicking a new menu entry.

Storage
Add a new "Qubes Storage Manager" that would show, in a tree view with pools as parent and contained VMs as children, all VMs, their disk space used, and that allows to easily launch Baobab, Nautilus and Terminal in the VMs.

Provide an XFCE panel widget that shows the current free space in the default pool and launches the "Qubes File Manager"

Devices
Add a new "Qubes Device Manager" that would show, in a tree view, all devices and the VMs/USB hubs/etc. they are physically attached to in a tree, as well the name of the VM they are logically assigned to, and allows to launch some sort of Device Manager app and Terminal in the VMs.

Change the devices tray icon to open it on double click or when clicking a new menu entry.

Also fix the devices tray icon to use a different icon for attached and unattached devices.

Network
Add a new "Qubes Network Manager" that would show, in a tree view, all VMs with VMs that have them as the netvm as children, as well as other networking details like IP addresses and would allow to configure the firewall, and allows to launch some sort of graphical version of "netstat" in the VM or the Terminal. This would also contain transient data like network recv/send bytes used by each VM.

Provide an XFCE panel widget that shows the current total network usage, that opens it on click.

Configuration
Add a new "Qubes Configuration Manager" that would show, in a tree view with label colors as parents and VMs as children, all VMs and all their preferences and open up the preference dialog on right click, and allow to launch Settings apps and Terminal in VMs, and also allow to set Qubes preferences and edit Qubes RPC policies.

This would be launched from the system menu, replacing Qubes preferences.

[qubesuser]

I agree.

My suggestion would be to write a bunch of applications with a similar UI, one for each concern.

This separation would essentially mimic the way traditional operating systems manage resources, but one could also have a single application with multiple tabs, and perhaps a way to look at a given VM in other apps/tabs (e.g. in Windows you use Explorer/WinDirStat to look at storage, Task Manager for CPU/memory/I/O usage, Network control panel for network, Device Manager for devices).

Tree views would become list views when sorted.

Running VMs
Add a new "Qubes Task Manager" that would show, in a list view, running VMs, their CPU, memory, network and disk I/O usage, as percentages and graphs (only update the graphs when the window is visible!), and allows to easily launch System Monitor and Terminal in the VMs

Change to the Qubes domains tray icon to open it on double click or when clicking a new menu entry.

Storage
Add a new "Qubes Storage Manager" that would show, in a tree view with pools as parent and contained VMs as children, all VMs, their disk space used, and that allows to easily launch Baobab, Nautilus and Terminal in the VMs.

Provide an XFCE panel widget that shows the current free space in the default pool and launches the "Qubes File Manager"

Devices
Add a new "Qubes Device Manager" that would show, in a tree view, all devices and the VMs/USB hubs/etc. they are physically attached to in a tree, as well the name of the VM they are logically assigned to, and allows to launch some sort of Device Manager app and Terminal in the VMs.

Change the devices tray icon to open it on double click or when clicking a new menu entry.

Also fix the devices tray icon to use a different icon for attached and unattached devices.

Network
Add a new "Qubes Network Manager" that would show, in a tree view, all VMs with VMs that have them as the netvm as children, as well as other networking details like IP addresses and would allow to configure the firewall, and allows to launch some sort of graphical version of "netstat" in the VM or the Terminal. This would also contain transient data like network recv/send bytes used by each VM.

Provide an XFCE panel widget that shows the current total network usage, that opens it on click.

Configuration
Add a new "Qubes Configuration Manager" that would show, in a tree view with label colors as parents and VMs as children, all VMs and all their preferences and open up the preference dialog on right click, and allow to launch Settings apps and Terminal in VMs, and also allow to set Qubes preferences and edit Qubes RPC policies.

This would be launched from the system menu, replacing Qubes preferences.

[marmarek]

@rootkovska what do you think about all this?

[marmarek]

@rootkovska what do you think about all this?

[SimonSelg]

@na-- : You can view the CPU/Memory usage per vm using xentop, which is installed in dom0 (sudo xentop -f).

@qubesuser: I really like your idea of having xfce4 panels widgets for that purpose. At least one that shows the current system load (cpu, memory, disk i/o), having to go through xentop is somewhat annoying.

Anyways, I'd like to contribute here - my python skills aren't that bad, and I have some free time on my hand.

[SimonSelg]

@na-- : You can view the CPU/Memory usage per vm using xentop, which is installed in dom0 (sudo xentop -f).

@qubesuser: I really like your idea of having xfce4 panels widgets for that purpose. At least one that shows the current system load (cpu, memory, disk i/o), having to go through xentop is somewhat annoying.

Anyways, I'd like to contribute here - my python skills aren't that bad, and I have some free time on my hand.

[na--]

@SimonSelg: thanks! I feel like I should have known about xentop after several years of using Qubes... I guess the old qubes manager was so good that I never needed it, heh :)

@qubesuser: while I would personally prefer a more centralized solution that allows for an easier bird's eye view of the whole system state, what you describe would probably be an improvement over the current state. I have a few concerns with such a strategy:

• Implementing and supporting a whole bunch of widgets and apps would probably be a more difficult and error-prone undertaking than just recreating an improved centralized qubes-manager for 4.0. I may be mistaken, I'm not very familiar with the Qubes codebase and the implementation challenges with the old manager and current widgets.
• Keeping the state consistent between all of the widgets and apps and the actual system state especially seems like a challenge. Today I hit a few variants of this issue - the first time the microphone was attached to a VM (I could record sound in the VM) while the device widget showed it as unattached. The second time a new block device was opened in dom0 but the widget never realized if. It seems that a refresh button on such state-sensitive widgets and apps is a must, or better yet - the ability to restart them like we could qubes-manager.
• Where are you going to show information like the template, netvm or kernel version for multiple VMs? In the "Task Manager" or "Configuration Manager" or both? I feel like that information could be useful and pertinent in both places. Used and allowed storage for multiple VMs can also be useful in the "Configuration Manager as well as the "Storage Manager". So it seems that these managers would either have a lot of duplicate information to be useful or to be very narrow siloed things that users have to constantly jump between. Ergo, a single unified manager could offer a better UX for the invested effort.
• Having some shortcuts that launch terminal, nautilus, baobab, etc. directly in some widgets/managers could be problematic because different qube can be different distributions or OSes or even some stuff like unikernels, so this should be user configurable like the current application shortcuts
• Trying to imitate how "normal" OSes handle configuration in Qubes isn't necessarily a good idea - there are very fundamental differences between the two. In an OS like Windows things like files, processes, network connections and disk drives are fundamentally different loosely-coupled things that can be used semi-independently of one another by lots of unconnected processes. So accordingly the tools to configure and explore them can be loosely coupled and disparate. In Qubes, the things we are discussing are all different aspects of the main isolation mechanism - security domains, the current state and configuration of which is something much more tightly coupled.

The old qubes manager basically did 3 different jobs at once:

• Displayed a big chunk of the current system state information in an easy to grasp way. Most of it was shown in a single table that allowed sorting and understanding the current state at a glance, while some was tucked away in the settings dialog. There were three types of information:
  • operational (ephemeral) information: which VMs are running/starting/stopping, how much CPU and RAM they use, if the mic or a block device is currently attached
  • configuration (persistent) information: what's the VM type, label, template, netvm; some configuration information was not shown in the table by default (like kernel version, allowed storage), but it could have been
  • something in-between: how much space is currently used by the VM, date of last backup (don't remember if that could actually be shown the table)
• Allowed us to change the persistent configuration for each VM - that mostly happened via the same VM settings window that's still present in 4.0
• Allowed us to change the operational (ephemeral) state of VMs - start/stop/restart/pause/kill them, attach block devices to them (sadly no USB), but did not allow us to start any of the apps in the VM (except by very not-user-friendly "Run a command") - for that we had to go to the KDE/xfce "start" menu.

I understand how the above could be somewhat confusing, especially for new users. But it was just so darn useful and convenient :) I don't see anything there that can't be fixed or improved. At the same time I think that trying to decompose and replace all of the different functions that the qubes manager did only makes everything more confusing and difficult to use, both for beginners but especially for advanced users.

[na--]

@SimonSelg: thanks! I feel like I should have known about xentop after several years of using Qubes... I guess the old qubes manager was so good that I never needed it, heh :)

@qubesuser: while I would personally prefer a more centralized solution that allows for an easier bird's eye view of the whole system state, what you describe would probably be an improvement over the current state. I have a few concerns with such a strategy:

• Implementing and supporting a whole bunch of widgets and apps would probably be a more difficult and error-prone undertaking than just recreating an improved centralized qubes-manager for 4.0. I may be mistaken, I'm not very familiar with the Qubes codebase and the implementation challenges with the old manager and current widgets.
• Keeping the state consistent between all of the widgets and apps and the actual system state especially seems like a challenge. Today I hit a few variants of this issue - the first time the microphone was attached to a VM (I could record sound in the VM) while the device widget showed it as unattached. The second time a new block device was opened in dom0 but the widget never realized if. It seems that a refresh button on such state-sensitive widgets and apps is a must, or better yet - the ability to restart them like we could qubes-manager.
• Where are you going to show information like the template, netvm or kernel version for multiple VMs? In the "Task Manager" or "Configuration Manager" or both? I feel like that information could be useful and pertinent in both places. Used and allowed storage for multiple VMs can also be useful in the "Configuration Manager as well as the "Storage Manager". So it seems that these managers would either have a lot of duplicate information to be useful or to be very narrow siloed things that users have to constantly jump between. Ergo, a single unified manager could offer a better UX for the invested effort.
• Having some shortcuts that launch terminal, nautilus, baobab, etc. directly in some widgets/managers could be problematic because different qube can be different distributions or OSes or even some stuff like unikernels, so this should be user configurable like the current application shortcuts
• Trying to imitate how "normal" OSes handle configuration in Qubes isn't necessarily a good idea - there are very fundamental differences between the two. In an OS like Windows things like files, processes, network connections and disk drives are fundamentally different loosely-coupled things that can be used semi-independently of one another by lots of unconnected processes. So accordingly the tools to configure and explore them can be loosely coupled and disparate. In Qubes, the things we are discussing are all different aspects of the main isolation mechanism - security domains, the current state and configuration of which is something much more tightly coupled.

The old qubes manager basically did 3 different jobs at once:

• Displayed a big chunk of the current system state information in an easy to grasp way. Most of it was shown in a single table that allowed sorting and understanding the current state at a glance, while some was tucked away in the settings dialog. There were three types of information:
  • operational (ephemeral) information: which VMs are running/starting/stopping, how much CPU and RAM they use, if the mic or a block device is currently attached
  • configuration (persistent) information: what's the VM type, label, template, netvm; some configuration information was not shown in the table by default (like kernel version, allowed storage), but it could have been
  • something in-between: how much space is currently used by the VM, date of last backup (don't remember if that could actually be shown the table)
• Allowed us to change the persistent configuration for each VM - that mostly happened via the same VM settings window that's still present in 4.0
• Allowed us to change the operational (ephemeral) state of VMs - start/stop/restart/pause/kill them, attach block devices to them (sadly no USB), but did not allow us to start any of the apps in the VM (except by very not-user-friendly "Run a command") - for that we had to go to the KDE/xfce "start" menu.

I understand how the above could be somewhat confusing, especially for new users. But it was just so darn useful and convenient :) I don't see anything there that can't be fixed or improved. At the same time I think that trying to decompose and replace all of the different functions that the qubes manager did only makes everything more confusing and difficult to use, both for beginners but especially for advanced users.

[andrewdavidwong]

There's also a lot of good discussion on this issue in this qubes-users thread:
https://groups.google.com/d/topic/qubes-users/e5rGdU73QcU/discussion

[andrewdavidwong]

There's also a lot of good discussion on this issue in this qubes-users thread:
https://groups.google.com/d/topic/qubes-users/e5rGdU73QcU/discussion

[rootkovska]

We definitely don't want to create, maintain and force the user to use just The One Centralized Qubes Apps. This is simply not how modern OSes work. As @qubesuser mentioned above, we need specialized apps for different purposes. The decomposition of the Qubes Manager we did for 4.0 has been the first step into this direction. Soon we will write an app for volume/template/updates/backups management. This will be a separate app from the Qubes (Task) Manager applet. Just like on other systems there are different apps/applets/widgets for different things.

[rootkovska]

We definitely don't want to create, maintain and force the user to use just The One Centralized Qubes Apps. This is simply not how modern OSes work. As @qubesuser mentioned above, we need specialized apps for different purposes. The decomposition of the Qubes Manager we did for 4.0 has been the first step into this direction. Soon we will write an app for volume/template/updates/backups management. This will be a separate app from the Qubes (Task) Manager applet. Just like on other systems there are different apps/applets/widgets for different things.

[marmarek]

Just like on other systems there are different apps/applets/widgets for different things.

Well, if you look into gnome, they actually integrated multiple widgets (network manager, volume control, logout, brightness, power manager) into one widget. So this is exactly the opposite direction...

[marmarek]

Just like on other systems there are different apps/applets/widgets for different things.

Well, if you look into gnome, they actually integrated multiple widgets (network manager, volume control, logout, brightness, power manager) into one widget. So this is exactly the opposite direction...

[3hhh]

Just like on other systems there are different apps/applets/widgets for different things.

Well, if you look into gnome, they actually integrated multiple widgets (network manager, volume control, logout, brightness, power manager) into one widget. So this is exactly the opposite direction...

Decomposition of code is good, decomposition of the main configuration interface not so as users want to have one central place they need to look at to configure their OS.
So a plugin or app-like model for a central management interface seems ideal. Plugins might give a more integrated look & feel (centrally managed), apps might be more easy to customize.
Also backend devs don't really want to care about the GUI, so some interface to advertise options to the frontend should be helpful.

Examples that I'm aware of:

• SUSE Linux yast (each of their plugins even has an own package and can be installed & uninstalled by itself, the GUI just seems to modify the respective config files)
• openwrt luci (web interface, other than that pretty much the same approach as yast)
• Windows control panel (more app based, lacks coherent look & feel)
• xfce control panel

[3hhh]

Just like on other systems there are different apps/applets/widgets for different things.

Well, if you look into gnome, they actually integrated multiple widgets (network manager, volume control, logout, brightness, power manager) into one widget. So this is exactly the opposite direction...

Decomposition of code is good, decomposition of the main configuration interface not so as users want to have one central place they need to look at to configure their OS.
So a plugin or app-like model for a central management interface seems ideal. Plugins might give a more integrated look & feel (centrally managed), apps might be more easy to customize.
Also backend devs don't really want to care about the GUI, so some interface to advertise options to the frontend should be helpful.

Examples that I'm aware of:

• SUSE Linux yast (each of their plugins even has an own package and can be installed & uninstalled by itself, the GUI just seems to modify the respective config files)
• openwrt luci (web interface, other than that pretty much the same approach as yast)
• Windows control panel (more app based, lacks coherent look & feel)
• xfce control panel

[andrewdavidwong]

Further discussion and feedback:
https://www.reddit.com/r/Qubes/comments/790jr4/qubes_40_rc1rc2_updates/

[andrewdavidwong]

Further discussion and feedback:
https://www.reddit.com/r/Qubes/comments/790jr4/qubes_40_rc1rc2_updates/

[section0x8]

This is simply not how modern OSes work.

I think all OSes have a control panel of some sort. I'm not sure why Qubes should be any different.

[section0x8]

This is simply not how modern OSes work.

I think all OSes have a control panel of some sort. I'm not sure why Qubes should be any different.

[errin07]

For me it is not about a control panel. The vm-settings option is in 2 places, easy to find. The qubes-manager for me was in the 1st place a system-monitor. You had to add a popup dialogue "VM is starting" as a "minute fix" because there was no user feedback at all. The app-menu can't do that, in fact for now it gives out wrong information for me what is template and what is appvm and which colors they have.
I needed qubes-manager for:

1. the quick overview+feedback of the whole system I had (every VM, state, templates used, color, net-vm used. mem, updateable, had errors etc.) where I could even order the VMs, the qubes-manager then had the
2. practical benefit to perform easy actions like starting/stop/pause (clone/backup/restore) or attach block devices without going to cli.

So it would be nice to address at least point 1) in a qubes specific way while point 2) gets split into different widgets for differents tasks.

[errin07]

For me it is not about a control panel. The vm-settings option is in 2 places, easy to find. The qubes-manager for me was in the 1st place a system-monitor. You had to add a popup dialogue "VM is starting" as a "minute fix" because there was no user feedback at all. The app-menu can't do that, in fact for now it gives out wrong information for me what is template and what is appvm and which colors they have.
I needed qubes-manager for:

1. the quick overview+feedback of the whole system I had (every VM, state, templates used, color, net-vm used. mem, updateable, had errors etc.) where I could even order the VMs, the qubes-manager then had the
2. practical benefit to perform easy actions like starting/stop/pause (clone/backup/restore) or attach block devices without going to cli.

So it would be nice to address at least point 1) in a qubes specific way while point 2) gets split into different widgets for differents tasks.

[qubesuser]

It might make sense to just make the old Qubes Manager code work with the new admin API and then reinvent the UI as a successive step, so that Qubes 4.0 can be released in a timely manner and be at least somewhat usable by non/less-technical users, which is currently impossible due to the lack of an UI to do many things.

[qubesuser]

It might make sense to just make the old Qubes Manager code work with the new admin API and then reinvent the UI as a successive step, so that Qubes 4.0 can be released in a timely manner and be at least somewhat usable by non/less-technical users, which is currently impossible due to the lack of an UI to do many things.

[marmarek]

Well, one of the reasons why we're ditched old Qubes Manager is the architecture of its code, especially the main window. In many cases it does things directly with underlying lowlevel API, subverting qubes-core. Having such things in Qubes 4.0 is no-go, everything should go through official (Admin) API.
Rewriting main window handling code to proper API will be a lot of work, so not something we want to do if we're going to replace it anyway.
But, if someone could contribute that migration, I think we may include it as an alternative VM manager.

[marmarek]

Well, one of the reasons why we're ditched old Qubes Manager is the architecture of its code, especially the main window. In many cases it does things directly with underlying lowlevel API, subverting qubes-core. Having such things in Qubes 4.0 is no-go, everything should go through official (Admin) API.
Rewriting main window handling code to proper API will be a lot of work, so not something we want to do if we're going to replace it anyway.
But, if someone could contribute that migration, I think we may include it as an alternative VM manager.

[tasket]

An assessment of 'modern desktop OSes' would mean paying heed to how Windows does it and regarding the Linux options as "so bad you cannot even give them away for free". Too many devs ignore defacto standards when it comes to personal computing, and also not realizing that much of those standards can only be understood by observation bc Microsoft is not going to write the book for us.

Chapter 1, if such a book existed, would impress on feature-stability and UI stability (tellingly, these are not concepts discussed around FOSS desktops). People walk away from shaky platforms, no matter how positive they felt initially or how well-abstracted the layers underneath.

The trade-off we seem to be making at the moment is to dump critical UI so that eventual replacement(s) will readily port to whatever hypervisor+hardware in the future. That could chain ITL and contributors to R3.2 support for extended periods and also put pressure on Qubes' R4 API to rapidly expand in complexity. I would opt for a different tradeoff: Keep Qubes Manager and slowly move some functions (starting with backup/restore) to different apps.

[tasket]

An assessment of 'modern desktop OSes' would mean paying heed to how Windows does it and regarding the Linux options as "so bad you cannot even give them away for free". Too many devs ignore defacto standards when it comes to personal computing, and also not realizing that much of those standards can only be understood by observation bc Microsoft is not going to write the book for us.

Chapter 1, if such a book existed, would impress on feature-stability and UI stability (tellingly, these are not concepts discussed around FOSS desktops). People walk away from shaky platforms, no matter how positive they felt initially or how well-abstracted the layers underneath.

The trade-off we seem to be making at the moment is to dump critical UI so that eventual replacement(s) will readily port to whatever hypervisor+hardware in the future. That could chain ITL and contributors to R3.2 support for extended periods and also put pressure on Qubes' R4 API to rapidly expand in complexity. I would opt for a different tradeoff: Keep Qubes Manager and slowly move some functions (starting with backup/restore) to different apps.

[qubesuser]

@marmarek any UI design probably needs a graphical xentop / "task manager" tool that includes a sortable list view with VMs as rows and CPU, memory, disk, network usage as columns, and the difference between that and Qubes Manager is essentially a bunch of additional columns for persistent state and the right click menu/toolbar actions, so most work done on a 4.0 Qubes Manager should at least be reusable for the "task manager" tool.

[qubesuser]

@marmarek any UI design probably needs a graphical xentop / "task manager" tool that includes a sortable list view with VMs as rows and CPU, memory, disk, network usage as columns, and the difference between that and Qubes Manager is essentially a bunch of additional columns for persistent state and the right click menu/toolbar actions, so most work done on a 4.0 Qubes Manager should at least be reusable for the "task manager" tool.

[lunarthegrey]

Putting my 2 cents in. I think it was silly to remove the Qubes Manager in the first place, it's one thing I really loved using and somewhere I could go to get a total overview of everything. Qubes shouldn't follow the development of "modern OSes" just because "modern OSes".

[lunarthegrey]

Putting my 2 cents in. I think it was silly to remove the Qubes Manager in the first place, it's one thing I really loved using and somewhere I could go to get a total overview of everything. Qubes shouldn't follow the development of "modern OSes" just because "modern OSes".

[n13]

Data point: As somebody who just installed qubes, and found it surprisingly usable, the absence of qubes manager is baffling. For example, I have no clue how much total disk space is available. I googled it, and found multiple references to the unicorn, qubes manager or qubes vm manager.

As Einstein said, make it as simple as possible, but not simpler.

I read all the discussion on the problems with Qubes Manager, and I can see the issues. But if it does some not so good things under the hood, surely it could be shipped and bit by bit improved to instead use the APIs that the command line tools use to do its work.

From a usability perspective it would be good to have a VM manager, to get a quick overview of VMs and a disk manager to have a quick overview of disk usage. Like a disk utility.

On a practical level, 95% of what I wanted to do in the last 2 hours was in qubes manager. I want to do X, I google for it, instructions read "Open qubes manager...." - so the removal of this tool made googling documentation pretty much useless. And so productivity or even getting familiar with the system has become super hard.

Adding this as a newbie comment.

[n13]

Data point: As somebody who just installed qubes, and found it surprisingly usable, the absence of qubes manager is baffling. For example, I have no clue how much total disk space is available. I googled it, and found multiple references to the unicorn, qubes manager or qubes vm manager.

As Einstein said, make it as simple as possible, but not simpler.

I read all the discussion on the problems with Qubes Manager, and I can see the issues. But if it does some not so good things under the hood, surely it could be shipped and bit by bit improved to instead use the APIs that the command line tools use to do its work.

From a usability perspective it would be good to have a VM manager, to get a quick overview of VMs and a disk manager to have a quick overview of disk usage. Like a disk utility.

On a practical level, 95% of what I wanted to do in the last 2 hours was in qubes manager. I want to do X, I google for it, instructions read "Open qubes manager...." - so the removal of this tool made googling documentation pretty much useless. And so productivity or even getting familiar with the system has become super hard.

Adding this as a newbie comment.

[tasket]

I might as well link to the discussion in qubes-users:

https://groups.google.com/d/msgid/qubes-users/eddf5625-11ca-40d9-be53-190c60f366fe%40googlegroups.com

On a practical level, 95% of what I wanted to do in the last 2 hours was in qubes manager.

If articles and docs keep referring to a component as a starting point, that's usually a sign that its functional because people can understand the system through it. This also suggests the component really isn't "optional".

People come to Qubes because they want to focus on security domains. Qubes Manager did that admirably. In an age when 'dashboards' that focus the user on pertinent objects/info are all the rage, R4.0 seems to be going in the wrong direction. I'd support the return of QM and even adding to its functions and reach.

[tasket]

I might as well link to the discussion in qubes-users:

https://groups.google.com/d/msgid/qubes-users/eddf5625-11ca-40d9-be53-190c60f366fe%40googlegroups.com

On a practical level, 95% of what I wanted to do in the last 2 hours was in qubes manager.

If articles and docs keep referring to a component as a starting point, that's usually a sign that its functional because people can understand the system through it. This also suggests the component really isn't "optional".

People come to Qubes because they want to focus on security domains. Qubes Manager did that admirably. In an age when 'dashboards' that focus the user on pertinent objects/info are all the rage, R4.0 seems to be going in the wrong direction. I'd support the return of QM and even adding to its functions and reach.

[mannp]

I guess there needs to be at least a warning to the user that they have ran out of space and the system is about to corrupt itself.

I am trying to recover from such a state and however much I love using qubes, its truly tedious.

[mannp]

I guess there needs to be at least a warning to the user that they have ran out of space and the system is about to corrupt itself.

I am trying to recover from such a state and however much I love using qubes, its truly tedious.

[marmarek]

configuration (persistent) information: what's the VM type, label, template, netvm; some configuration information was not shown in the table by default (like kernel version, allowed storage), but it could have been
something in-between: how much space is currently used by the VM, date of last backup (don't remember if that could actually be shown the table)

We've talked internally about possible solutions for this problem and concluded that, given the time constraints, we won't have new application for this before final 4.0. So, we're going to resurrect this part of Qubes Manager. The static part of the main table, without any automatic updating logic (there will be "refresh" button) or other things already covered by new widgets (like device attaching).

[marmarek]

configuration (persistent) information: what's the VM type, label, template, netvm; some configuration information was not shown in the table by default (like kernel version, allowed storage), but it could have been
something in-between: how much space is currently used by the VM, date of last backup (don't remember if that could actually be shown the table)

We've talked internally about possible solutions for this problem and concluded that, given the time constraints, we won't have new application for this before final 4.0. So, we're going to resurrect this part of Qubes Manager. The static part of the main table, without any automatic updating logic (there will be "refresh" button) or other things already covered by new widgets (like device attaching).

[najamelan]

I would like to suggest also thinking about debugging. Centralized place to see logs and failed systemd services in all VM's, especially qubes services.

Personally I'm in favor of having a centralized management, in a separate VM, but have one well designed gui application (not running in dom0) from where one can manage everything that is qubes specific (et. what makes qubes different from OS users are used to). That would be a great help to a new user like me. Current situation makes me blind as to the state of the system until I figure out where I have to look, which command line command, which log file and in cubes these are spread out over different domains to make things worse.

That's bad for usability, debugging and security.

Modern OS does work with integration. Systemd is an attempt at this (with poor front end for the moment), configuration tools like gnome-settings is another example. For servers you will get stuff like CPanel, ...

Overview is important!

[najamelan]

I would like to suggest also thinking about debugging. Centralized place to see logs and failed systemd services in all VM's, especially qubes services.

Personally I'm in favor of having a centralized management, in a separate VM, but have one well designed gui application (not running in dom0) from where one can manage everything that is qubes specific (et. what makes qubes different from OS users are used to). That would be a great help to a new user like me. Current situation makes me blind as to the state of the system until I figure out where I have to look, which command line command, which log file and in cubes these are spread out over different domains to make things worse.

That's bad for usability, debugging and security.

Modern OS does work with integration. Systemd is an attempt at this (with poor front end for the moment), configuration tools like gnome-settings is another example. For servers you will get stuff like CPanel, ...

Overview is important!

[Shane-Optima]

This is simply not how modern OSes work. As @qubesuser mentioned above, we need specialized apps for different purposes.

I'm not certain how to say this without sounding unbearably snarky, but... really? I mean, has Windows Explorer been split into three apps, one to rename files, one to copy them, one to delete them? Have "start menu" type buttons been decomposed into thirty different widgets covering the screen, each one launching a different type of application? I thought that end user applications had fairly broad but intuitive goals like "launching applications", "viewing and manipulating files".... or "viewing and interacting with VMs." Behind the scenes there could be two dozen totally modular executables, but the user is faced with one application for task.

...I thought? I mean I've not used anything after Windows 7, so it's possible I've missed some particularly horrific UI "revolution"

I won't spam points I've already said elsewhere, but I want to repeat that as a power user (not to be confused with expert), the best UI development of the 21st century has far and away been the little text box in the start menu, and I know many power users who would readily agree with me. That's because that little box does EVERYTHING... lets me change any setting, launch any program, open any file. It doesn't insist that I memorize a new UI or new incantations to recite. Not everything can be simplified to that extent, but I think it is an important example of the role and limitations of modularity.

I think everyone is totally on board with the idea of the Unix philosophy on the back end, but we're less convinced that it entails the complete abandonment of elegant front-ends that are capable of launching and unifying these "specialized apps" into a compact manner that makes perfect intuitive sense to people who do understand that Qubes is made up of many different VMs and wish to interact with this one or that one. Which is not to say your criticisms of the Qubes Manager do not make sense--they do, but an instance on pure and absolute modularity and orthogonality and separation in the final user-facing interface is... well, it doesn't make sense to a lot of us.

I'll leave it at that. Thank you again for everything you've done. Though I may be only a semi-technical user, I have usually been very impressed with and have remained in total agreement with your insistence on correctness.

[Shane-Optima]

This is simply not how modern OSes work. As @qubesuser mentioned above, we need specialized apps for different purposes.

I'm not certain how to say this without sounding unbearably snarky, but... really? I mean, has Windows Explorer been split into three apps, one to rename files, one to copy them, one to delete them? Have "start menu" type buttons been decomposed into thirty different widgets covering the screen, each one launching a different type of application? I thought that end user applications had fairly broad but intuitive goals like "launching applications", "viewing and manipulating files".... or "viewing and interacting with VMs." Behind the scenes there could be two dozen totally modular executables, but the user is faced with one application for task.

...I thought? I mean I've not used anything after Windows 7, so it's possible I've missed some particularly horrific UI "revolution"

I won't spam points I've already said elsewhere, but I want to repeat that as a power user (not to be confused with expert), the best UI development of the 21st century has far and away been the little text box in the start menu, and I know many power users who would readily agree with me. That's because that little box does EVERYTHING... lets me change any setting, launch any program, open any file. It doesn't insist that I memorize a new UI or new incantations to recite. Not everything can be simplified to that extent, but I think it is an important example of the role and limitations of modularity.

I think everyone is totally on board with the idea of the Unix philosophy on the back end, but we're less convinced that it entails the complete abandonment of elegant front-ends that are capable of launching and unifying these "specialized apps" into a compact manner that makes perfect intuitive sense to people who do understand that Qubes is made up of many different VMs and wish to interact with this one or that one. Which is not to say your criticisms of the Qubes Manager do not make sense--they do, but an instance on pure and absolute modularity and orthogonality and separation in the final user-facing interface is... well, it doesn't make sense to a lot of us.

I'll leave it at that. Thank you again for everything you've done. Though I may be only a semi-technical user, I have usually been very impressed with and have remained in total agreement with your insistence on correctness.

[zander]

@Shane-Optima the only way I could make Qubes 4 bearable was by running KDE on top of it with the "application dashboard" startmenu. Which is actually a full-screen thing and does search etc.

The good thing is that when the admin-api (and qrexec) become mature then people can write their own tools and have no need to use the ones that the core team creates.

[zander]

@Shane-Optima the only way I could make Qubes 4 bearable was by running KDE on top of it with the "application dashboard" startmenu. Which is actually a full-screen thing and does search etc.

The good thing is that when the admin-api (and qrexec) become mature then people can write their own tools and have no need to use the ones that the core team creates.

[marmarek]

For Xfce there is alternative menu, which also contains search: whisker menu. It's installed by default, you just need to add it to the panel. Also, launcher accessible with alt-f2 has menu search option when you press down arrow.

[marmarek]

For Xfce there is alternative menu, which also contains search: whisker menu. It's installed by default, you just need to add it to the panel. Also, launcher accessible with alt-f2 has menu search option when you press down arrow.

[Polygonbugs]

I really like Qubes OS 4.0 (Official release) than the previous one 3.2 almost everything except UX issues. I'm sorry for developers who made this incredible OS very hard but I think UX is still incomplete and almost unusable. I would understand if users stay 3.2, that would be lack, laggy, and buggy qubes GUI management tools. You should have dealt with more carefully when implementing new UI for managing OS. You already know that visibility is also one of the most important aspects of security.

I'm not sure what is your current goal for UI but it definitely need to be changed. In my opinion, I think you have three options. First, rebuild new Qubes-Manager. This one is something you don't like to do because of increased complexity by implementing admin API from 4.0. Also against policy of qubes decomposition which implemented due to excessive bug reports of old Qubes-Manager and possible future security issues (other reasons don't make sense). Though Qubes-Manager revived on 4.0 because of users' claim, I'm evident that you formally made it. It is super laggy, has more errors (I think the number of 4.0 Qubes-Manager level errors are almost as same as total 3.2 OS level errors), has no auto refresh. Second, HTML Qubes Management Tool. It is something like router managing pages on browser via remote protocols. Of course, it could be bad for security since it has to use internet browsers which have huge amount of vulnerabilities. Also updating browser would be difficult since dom0 is outdated fedora version so users have to manually upgrade. But if you could make this, there is some chance to make the UI more elegant and more powerful. Last one is focusing on widgets, which I think is your current goal. It has clear pros and cons. The advantage of using widget is good for someone using desktop machine with a lot of virtual desktops or laptop. Yeah, someone could argue that why don't we add extra monitors to a machine. But in case of laptop it would be very difficult and inefficient. Disadvantage is general inconvenience already explained by many users. However, this could be improved. I can give you concrete advice with this. Below is everything about it.

Adding New Widgets

• Qubes Backup / Restore Widget (Currently, users can use desktop launcher but these one are inconvenient)
• Qubes Create [Add a way to make static Disposable VMs] / Remove / Clone Widget
• Qubes Global Settings Widget (Currently, users can use desktop launcher but this one is inconvenient)
• Qubes dom0 temperature and performance checking Widget (This is just option)
• Qubes Offline Documentation Widget (Same online document found in here and install office-suite program to dom0 by default /This is just option)

Add features to current Widgets and Fix bugs

• Show all VMs list on VM-Management Widget including closed VM (Show state as color)
• Use vertical columns to devide VMs list when there are a lot of VMs on VM-Management Widget (Users will hate scrolling. Also some scroll bug when the panel is on bottom)
• Add user defined custom sorting feature and group/tag VMs to VM-Management Widget(such as firefox bookmark)
• Add searching filter to VM-Management Widget
• Add VM type (templateVM, AppVM ..) icon next to the colour icon on VM-Management Widget
• Show each VM's CPU usage and Memory usage as bar
• Fix current VM size showed on the VM-Management widget to use real VM size as appeared on Qubes-Manager
• Show Start+Restart buttons (When VM is off), Shutdown+Kill+Pause buttons (When VM is on), Kill button (When VM is not properly working)
• Fix bug that sucessfully closed VM is showed as not closed on VM-Management Widget
• Fix bug when two VMs are almost simultaneously starting, VM-Management Widget freeze at that moment
• Fix notification error that shutdowing VM is showed as "Starting On" #4000
• Add "Run command in qube" button on VM-Management Widget
• Add "Update qube" botton to Template VMs on VM-Management Widget
• Fix "Run Terminal" not working sometimes on VM-Management Widget
• Add 'seamless gui mode' check box to qube-settings
• Fix bug that inserted USB devices or other wired devices are not appeared to the Devices-Management widget
• Add drive performance to Disk-Space Widget

[Polygonbugs]

I really like Qubes OS 4.0 (Official release) than the previous one 3.2 almost everything except UX issues. I'm sorry for developers who made this incredible OS very hard but I think UX is still incomplete and almost unusable. I would understand if users stay 3.2, that would be lack, laggy, and buggy qubes GUI management tools. You should have dealt with more carefully when implementing new UI for managing OS. You already know that visibility is also one of the most important aspects of security.

I'm not sure what is your current goal for UI but it definitely need to be changed. In my opinion, I think you have three options. First, rebuild new Qubes-Manager. This one is something you don't like to do because of increased complexity by implementing admin API from 4.0. Also against policy of qubes decomposition which implemented due to excessive bug reports of old Qubes-Manager and possible future security issues (other reasons don't make sense). Though Qubes-Manager revived on 4.0 because of users' claim, I'm evident that you formally made it. It is super laggy, has more errors (I think the number of 4.0 Qubes-Manager level errors are almost as same as total 3.2 OS level errors), has no auto refresh. Second, HTML Qubes Management Tool. It is something like router managing pages on browser via remote protocols. Of course, it could be bad for security since it has to use internet browsers which have huge amount of vulnerabilities. Also updating browser would be difficult since dom0 is outdated fedora version so users have to manually upgrade. But if you could make this, there is some chance to make the UI more elegant and more powerful. Last one is focusing on widgets, which I think is your current goal. It has clear pros and cons. The advantage of using widget is good for someone using desktop machine with a lot of virtual desktops or laptop. Yeah, someone could argue that why don't we add extra monitors to a machine. But in case of laptop it would be very difficult and inefficient. Disadvantage is general inconvenience already explained by many users. However, this could be improved. I can give you concrete advice with this. Below is everything about it.

Adding New Widgets

• Qubes Backup / Restore Widget (Currently, users can use desktop launcher but these one are inconvenient)
• Qubes Create [Add a way to make static Disposable VMs] / Remove / Clone Widget
• Qubes Global Settings Widget (Currently, users can use desktop launcher but this one is inconvenient)
• Qubes dom0 temperature and performance checking Widget (This is just option)
• Qubes Offline Documentation Widget (Same online document found in here and install office-suite program to dom0 by default /This is just option)

Add features to current Widgets and Fix bugs

• Show all VMs list on VM-Management Widget including closed VM (Show state as color)
• Use vertical columns to devide VMs list when there are a lot of VMs on VM-Management Widget (Users will hate scrolling. Also some scroll bug when the panel is on bottom)
• Add user defined custom sorting feature and group/tag VMs to VM-Management Widget(such as firefox bookmark)
• Add searching filter to VM-Management Widget
• Add VM type (templateVM, AppVM ..) icon next to the colour icon on VM-Management Widget
• Show each VM's CPU usage and Memory usage as bar
• Fix current VM size showed on the VM-Management widget to use real VM size as appeared on Qubes-Manager
• Show Start+Restart buttons (When VM is off), Shutdown+Kill+Pause buttons (When VM is on), Kill button (When VM is not properly working)
• Fix bug that sucessfully closed VM is showed as not closed on VM-Management Widget
• Fix bug when two VMs are almost simultaneously starting, VM-Management Widget freeze at that moment
• Fix notification error that shutdowing VM is showed as "Starting On" #4000
• Add "Run command in qube" button on VM-Management Widget
• Add "Update qube" botton to Template VMs on VM-Management Widget
• Fix "Run Terminal" not working sometimes on VM-Management Widget
• Add 'seamless gui mode' check box to qube-settings
• Fix bug that inserted USB devices or other wired devices are not appeared to the Devices-Management widget
• Add drive performance to Disk-Space Widget